How We Were Able to Access User Personal Data
Written by Snir Aviv on
How We Were Able to Access User Personal Data
Written by Snir Aviv on
Introduction
During a penetration test conducted on a web application, a critical finding was discovered, allowing complete access to users’ private information through the leverage of Insecure Direct Object Reference (IDOR) vulnerability.
The web application provides the option to create and manage personal reports of registered accounts and export them to a different format, such as PDF.
How we Found the Critical Finding
Step 1: Interacting with the Web Application
Initially, we accessed the web platform with a low-level user. The business logic allows anyone to perform registration, as long as valid information is being filled during the process, such as ID, email address, and more.
After authenticating successfully, many requests are sent to the web application API, which mostly returns personal information about the logged-in user account. For example, the /v2/api/Reports endpoint is responsible for fetching the user’s reports, as follows:
Step 2: Assessing the Vulnerability
After investigating the application’s privilege mechanism, it was discovered that reports belonging to other users in the application can be fetched as the API endpoint was found to be vulnerable to an Insecure Direct Object Reference (IDOR) attack. It could be achieved by performing the following actions:
- Changing the Role parameter to a higher value in the hierarchy, such as Emp (stands for Employee).
- Changing the id parameter value to any numeric value.
Step 3: Putting All Together and Exploit
Using the returned parameters from step two, it was possible to craft an additional request found on the API. The /v2/api/Reports/DownloadReport API endpoint is responsible for generating a PDF report based on several provided information, such as a user identifier, an account identifier, and a full report name. As a result, a detailed PDF document containing highly sensitive information about the targeted account can be successfully retrieved by an adversary.
The obtained reports contained data such as account number, date of birth, full name, ID, and much more.
Mitigation
Clear Gate advised improving the authorization mechanism by that verifying the user’s identity correctly when the user tries to access reports in the system. Clear Gate confirmed that it was applied correctly and that the risk no longer applies.
References
Insecure Direct Object Reference Prevention Cheat Sheet – OWASP