Understanding the IDOR Vulnerability in Google’s Crisis Map That Exposed Registered Email Addresses
Google’s Crisis Map, an older platform designed for creating and sharing custom map data, required users to log in with their Google accounts to manage their maps and settings. While the service aimed to facilitate collaboration through shared access, it contained a severe security vulnerability linked to Insecure Direct Object References (IDOR) and incremental user IDs that exposed the email addresses of thousands of registered users.
Introduction to Google Crisis Map and Its Domain Settings
Used primarily for creating collaborative maps, Google Crisis Map’s features include map creation, editing, and domain management.
To access these features, users must first authenticate using their Google account credentials.
After logging in, users could go to their domain settings, where several configurable options are available. A critical component of these settings is the Members section, which lists email addresses of collaborators who have access to the maps. Users can invite others to collaborate through this interface.
Analyzing the Vulnerability: How Members Were Managed
Adding a new member involved sending a POST request to a URL structured like this:
https://google.org/crisismap/example.com/.adminThe request body contained two crucial fields:
new_user: the email address of the user to addnew_user.permission: the permission level assigned to the user
Upon submission, the webpage updated to reflect the newly added member in the Members list along with their email address.
Incremental User IDs in Permissions Handling
Examining the HTML form revealed that each member’s email was associated with a short numeric identifier, for example, 123456, embedded in the input fields’ name attributes related to permission levels, rather than the email address itself.
Further investigation showed that submitting a form with a different member ID (e.g., 123457.permission) allowed the addition of that member to the project. Crucially, this permitted the exposure of that user’s email address in the members list.
Exploiting IDOR to Enumerate All Registered Email Addresses
The user IDs were incremental, starting from 0 for the first registered user, then 1, and so on. Because the application did not enforce strict authorization checks on these ID inputs, an attacker could increment IDs sequentially to add arbitrary users as members and thereby access their email addresses.
This lack of access control on direct object references is a classic example of an IDOR vulnerability. Exploiting it allowed an attacker to enumerate the email addresses of all registered users on Google Crisis Map. At the time, the highest user ID was around 32,000, meaning tens of thousands of email addresses were potentially exposed.
Implications of the Vulnerability
- Privacy Risks: Exposure of email addresses compromises user privacy and can facilitate phishing and social engineering attacks.
- Security Threats: Attackers can leverage exposed email lists for targeted attacks, credential stuffing, or spam campaigns.
- Data Integrity: Unauthorized modifications to member lists could disrupt legitimate collaborations.
Broader Context of IDOR Vulnerabilities
IDOR remains one of the most common web vulnerabilities. According to the OWASP Top 10, improper access control issues lead to data breaches in numerous systems worldwide.
Large-scale enumeration attacks like this highlight the need for robust authorization checks on references such as user IDs, rather than relying on security through obscurity.
Key Takeaways and Best Practices to Prevent IDOR
- Implement Strong Authorization Checks: Ensure users can only access data and perform actions they are authorized for.
- Use Non-Guessable Identifiers: Replace incremental IDs with random, unique identifiers (UUIDs) to make enumeration difficult.
- Input Validation and Access Control: Always validate object references on the server side before processing requests.
- Regular Security Audits: Continuously test applications for IDOR and other vulnerabilities using automated scanners and manual penetration testing.
Timeline of the Vulnerability Disclosure
| Date | Event |
|---|---|
| December 12, 2018 | Vulnerability initially reported |
| December 13, 2018 | Priority changed to P2, then escalated to P1 the same day |
| December 13, 2018 | Investigation began |
| December 18, 2018 | Security reward issued and issue mitigated |
Conclusion
The discovery of an IDOR vulnerability in Google’s Crisis Map platform underscores the importance of strict access control and the risks posed by predictable, incremental user identifiers. This incident serves as a reminder for organizations to continuously monitor and secure their web applications to protect user data and maintain trust.
For web developers and security professionals, adopting best practices such as using non-predictable identifiers and enforcing rigorous authorization mechanisms is critical to preventing similar security flaws.
References:
