IDOR Case Study: Manipulating Billing Information and Viewing Payment History

Manipulating Billing Information and Viewing Payment History: How IDOR and Response Manipulation Allowed Access to Billing Information

We discovered an Insecure Direct Object Reference (IDOR) vulnerability on the redacted website that allowed unauthorized access to billing details and sensitive information. If exploited by attackers, this vulnerability could have led to serious security breaches.

While exploring a website’s subscription and payment management system, we came across an interesting yet concerning security vulnerability known as IDOR (Insecure Direct Object Reference). This type of vulnerability, although sometimes overlooked, can have significant impact. In this case, we discovered that it was possible to alter and access the billing details of other subscribed users, something that should have been securely protected.

What is IDOR Vulnerability

Insecure Direct Object Reference (IDOR) is a type of security vulnerability that occurs when an application provides direct access to objects based on user-supplied input, without properly validating whether the user is authorized to access those objects. Essentially, if a user can manipulate a reference (such as an ID in a URL) to access data or resources they shouldn’t have access to, an IDOR vulnerability is present. This can lead to unauthorized viewing, editing, or deletion of sensitive data, depending on how the application is structured.

Breakdown of IDOR Vulnerability

Here’s a breakdown of how the vulnerability was exploited:

1. Initial Setup: First, two accounts were involved: User A (a free account) and User B (a subscribed account).
   User A logged into their free account and User B into their subscribed account from different browsers or incognito windows.

2. Changing the Billing Address: While logged in as User A, we went to the account billing information page and made changes. Meanwhile, User B’s account had a different billing address.

3. Exploiting the Vulnerability: We navigated to the account settings page, where users could update their account information like name, phone number, etc. we noticed that email addresses are not supposed to be changed, however, by intercepting the POST request and manipulating the “newEmail” parameter, we could change Account A’s email address to match that of Account B.
   
                      
        
   
   On returning to the page, we were required to verify the new email (Account B).

 We were quite demotivated after this response but after working around the response manipulation, we found that when we access the settings page, and manipulate the “verified” parameter in the response (that is responsible for confirming that the user has verified the email), we could change the billing information of Account B’s account. we accessed the settings page and intercepted the response, we changed the “verified” parameter to true and forwarded it.

4. Results: Upon returning to User B’s account, we refreshed the page and noticed that the billing address had been overwritten with the one from User A. The billing information from User A was now visible in User B’s account.

5. Accessing Subscription History: But it didn’t stop there. User A, still logged into their account, could access the subscription history page.
   
   
   
   The history displayed was not User A’s but that of User B, revealing sensitive billing details that should have remained private.

This vulnerability is a textbook example of an IDOR bug. It allowed unauthorized users to not only view but also modify sensitive data belonging to others. The ability to overwrite a subscribed user’s billing information and view their subscription history could have serious impact, especially in scenarios where financial data is involved. This vulnerability occurred because the server mistakenly identified User A as User B due to the manipulation of the email change and verified parameter. As a result, the server displayed and allowed modifications to User B’s sensitive information, believing it was being accessed by the rightful owner.

How to Identify IDOR Vulnerabilities 

Basic IDOR: Modify the object ID in a URL or form field to access unauthorized resources (e.g., /profile?id=1234 to /profile?id=5678).
You can read about a similar real-case scenario here https://laburity.com/unveiling-improper-access-control-a-journey-into-admin-dashboards/

Horizontal Privilege Escalation: Change the user ID in an API request (e.g., /api/user/123/orders to /api/user/321/orders) to retrieve or manipulate another user’s order.

Vertical Privilege Escalation: Attempt to access an admin or privileged account by manipulating a regular user ID to an admin ID in the request URL or form fields (e.g., change account_role from user to admin).

Session Management: Modify session tokens or cookie values and see if it allows access to another user’s session.

Enumeration of Object IDs: Sequentially or randomly try different object IDs (e.g., /invoice/1001, /invoice/1002) to test if resources can be accessed without proper authorization.

HTTP Parameter Pollution: Submit multiple values for the same parameter to see how the application handles it (e.g., GET /api_v1/messages?user_id=123&user_id=321).

Blind IDOR: Attempt to exploit IDOR on endpoints that do not directly return sensitive information but cause indirect data leakage, such as through export files or notifications (e.g., changing user IDs in a request might trigger an email with leaked information).

Manipulating the Requested File Type: Modify the requested file type by appending .json, .xml, or other file extensions to the URL (e.g., /profile/1234.json) to see if this bypasses access control.

Changing the HTTP Request Method: If a GET request fails to access a resource, attempt to change the request method to PUT or POST and see if it returns something different.

Wildcard Parameter Manipulation: Instead of specifying a particular user ID, use a wildcard character (e.g., *, %, _, or .) in place of the ID to see if the backend returns data for all users (e.g., GET /api/users/* or GET /api/users/%).

IDOR Testing Tool-kit

• Auth Analyzer (Burp Suite Extension): This extension analyzes authentication and authorization vulnerabilities in applications. It is particularly useful for detecting IDOR vulnerabilities by comparing user roles and testing access controls on various objects.
  
  
  

• Autorize (Burp Suite Extension): Automatically checks for authorization issues, including IDORs. It replays requests with different user tokens or lower-privileged sessions to see if unauthorized access is possible.
  

• Param Miner (Burp Suite Extension): Analyzes parameters to uncover hidden ones that may not be visible in the request but can be manipulated to test IDOR vulnerabilities. It suggests potential parameters for testing authorization checks.
  
  

• AuthMatrix: Facilitates both manual and automated testing of authorization logic across different user roles. It helps identify IDORs by mapping users to resources and checking for inappropriate access

IDOR Vulnerability Bypasses and Common Test Cases

Brute Forcing Object IDs: Use tool like Burp Suite Intruder to brute-force object IDs. For Example:

Parameter Tampering: Change the parameter value in a URL, form field, or header to see if unauthorized access to other users’ data is possible. For Example:

POST /orders/view?order_id=1001

(Modify order_id to another value: 1002, 1003, etc.)


Alternate Data Representation: If an application allows both numeric and alphanumeric IDs, it may mishandle authorization checks when different formats are used. Try accessing a resource using different formats for the same ID (e.g., hexadecimal, octal, base64). For Example:

GET /user/1001 → Try: GET /user/0x3E9

Cookie or Token Manipulation: Edit the cookie or token to impersonate another user or gain access to unauthorized data. For Example:

Cookie: session=eyJ1c2VyX2lkIjoxMDAxfQ== → Change user_id in the JWT

You can read more about JSON Web Token (JWT) and its attacks here https://laburity.com/understanding-jwt-basics-and-security-risks/

Referer/Origin Header Manipulation: Some applications rely on the Referer or Origin headers to determine if the request is authorized. Modify or remove these headers when sending requests to see if you can bypass access control. For Example:


Origin: https://trusted-domain.com → Change to: Origin: https://malicious-site.com


Race Condition Exploitation: Using race conditions, an attacker sends multiple concurrent requests, modifying the object ID mid-process. This can allow unauthorized access or operation completion without full validation. You can utilize tool like Turbo Intruder to send hundreds of concurrent requests, trying to bypass validation by creating a race condition. For Example:

A PHP Based Simple IDOR Lab

We’ve created a simple PHP-based web application that demonstrates how this vulnerability works in practice. You can download the lab and follow the instructions to exploit the vulnerability and understand how attackers manipulate URL parameters and cookies to gain unauthorized access.

You can find the lab setup and instructions in this GitHub repository:

https://github.com/Laburity/vulnerable-IDOR-lab

In this lab, you’ll see how profiles can be accessed and edited by modifying different parameters.

Feel free to clone the repository, experiment with the lab, and try out the solution.

Conclusion

In this case, we explored an IDOR vulnerability that allowed a user to manipulate account information they shouldn’t have had access to. This vulnerability highlighted the importance of validating user inputs and ensuring that data is properly protected from unauthorized access. The ability to change and view another user’s billing address and subscription history showed how small security oversights can lead to significant breaches.

Always validate that users can only interact with data they are authorized to access. It’s crucial to test how the application responds to manipulated requests. By altering parameters and observing the results, testers can uncover IDOR vulnerabilities and other bugs that might otherwise go unnoticed. Ensuring that the application properly handles unauthorized access attempts is very important.