Understanding IDORs

IDOR is a type of access control vulnerability. This security flaw occurs when an application relies on user-supplied input, such as object IDs, file names, or other identifiers, to access objects directly. IDOR is the abbreviation for Insecure Direct Object Reference.

Let's consider a simple example in order to understand the vulnerability better.

Consider a web application that allows users to access the details of a particular order using the following URL: https://examplestore.com/purchaseInfo?order_id=7890. In this scenario, the application retrieves purchase information from the backend database based on the order ID provided in the URL. However, if the application lacks proper access controls, an IDOR vulnerability can arise. Let's say a malicious user discovers that changing the order_id parameter allows them to view other users' purchase information. They modify the URL to https://examplestore.com/purchaseInfo?order_id=1234, which corresponds to a different order ID belonging to another user. As a result, they gain unauthorized access to someone else's purchase information, potentially exposing sensitive data like products purchased, payment details, and shipping addresses.

IDORs extend beyond solely accessing other users' information and can be used to modify data on behalf of another user.

Consider the below example.

Consider a social media platform that allows users to update their profile information, including their bio, through a POST request. The request is sent to the /update_profile endpoint with the following parameters in the request body:

1POST /update_profile
2Host: exsocialmedia.com
3Content-Type: application/x-www-form-urlencoded
4
5user_id=1234&bio=New+bio+content.
6

In a secure implementation, the application would validate that the user_id corresponds to the currently logged-in user before processing the request. However, if the application lacks proper validation and authorization checks, an IDOR vulnerability can occur.

An attacker could exploit this vulnerability by manipulating the user_id parameter in their own POST request. For example, the attacker modifies the request body to:

1POST /update_profile
2Host: exsocialmedia.com
3Content-Type: application/x-www-form-urlencoded
4
5user_id=1235&bio=modified+bio+content.
6

If the application fails to verify the user's identity and blindly updates the profile information based solely on the provided user_id, the attacker's request would be processed as if it came from the user with the ID 1235. As a result, the profile bio of user 1235 would be updated with the attacker's desired content, causing unauthorized modifications to another user's profile.

The above examples are simple scenarios of IDOR. In the coming sections we will learn about more advance techniques.

Root Causes

Insecure Direct Object References (IDORs) can occur due to various root causes within web applications. Insufficient authorization checks play a significant role, where applications fail to adequately verify user permissions, enabling attackers to manipulate parameters and bypass intended access controls. Directly referencing objects or resources without proper validation and contextual mapping can also lead to IDOR vulnerabilities. Additionally, the absence or misconfiguration of indirect access controls, such as session management or role-based access controls (RBAC), can provide opportunities for unauthorized access. Weak input validation and sanitization practices, coupled with failure to randomize object IDs and instead keeping references to data objects, like a file or a database entry, predictable contribute to IDOR risks.

Hunting for IDORs

The fundamental methodology for hunting IDORs involves the following steps. Firstly, create two distinct accounts on the target website. Next, explore various application features, with a focus on functionalities that either retrieve user information or modify user data. Finally, after identifying the features to test, capture the request and interchange the IDs in sensitive requests to verify if the returned information also undergoes changes.

However, IDORs are often not as straightforward as this, and applications may have implemented certain mechanisms to protect against them. Now, let's explore how we can bypass these protection mechanisms in order to exploit the vulnerability effectively.

Outsmarting IDOR Protection Mechanisms

i. Decrypting & Decoding IDs

Firstly, it is important not to overlook encoded and hashed IDs. When encountering a seemingly random string, it is advisable to suspect that it might be encoded and attempt to decode it. Base64, Url, etc are the most common encoding schemes used. Also it is recommended to try to decrypt encrypted IDs using hashes.com (or similar tools).

For example take a look at the IDs at this endpoint: https://examplestore.com/purchaseInfo?order_id=81dc9bdb52d04dc20036dbd8313ed055

https://examplestore.com/purchaseInfo?order_id=9996535e07258a7bbfd8b132435c5962

Even though this seems like extremely random order ids they are just MD5 encrypted versions of 1234 & 1235.

ii. HTTP Parameter Pollution

HTTP Parameter Pollution (HPP) is a technique that can be useful in testing for IDOR vulnerabilities because it allows you to manipulate parameters and potentially bypass certain protections implemented by the web application. By injecting multiple instances of the same parameter, you can assess how the application handles and processes those parameters, which can reveal potential IDOR vulnerabilities.

Consider this example which we saw earlier:

1POST /update_profile
2Host: exsocialmedia.com
3Content-Type: application/x-www-form-urlencoded
4
5user_id=1234&bio=New+bio+content.
6

Here If we just try to normally change the user_id we get a 401 unauthorized error. In order to bypass this we can try http parameter pollution as follows:

1POST /update_profile
2Host: exsocialmedia.com
3Content-Type: application/x-www-form-urlencoded
4
5user_id=1234&user_id=1235&bio=Modified Content.
6

iii Changing request methods

Changing the request methods might also help to bypass IDOR protections. If a particular HTTP request method does not yield the desired results, you can experiment with various other methods such as GET, POST, PUT, DELETE, PATCH, and more. Many applications allow multiple request methods to be used on the same endpoint, but they often neglect to implement consistent access control for each method.

Consider the social media example which we saw earlier.

1POST /update_profile
2Host: exsocialmedia.com
3Content-Type: application/x-www-form-urlencoded
4
5user_id=1234&bio=New+bio+content.
6

Here one can attempt to resend this request as a GET request as follows:

1GET /update_profile?user_id=1235&bio=Modified+Bio.
2Host: exsocialmedia.com
3Content-Type: application/x-www-form-urlencoded
4
5

This can potentially bypass IDOR protections.

iv. Wildcard characters

In some cases, applications may implement protection mechanisms to prevent IDOR vulnerabilities by validating the requested resource identifier against the user's permissions or ownership. However, if a wildcard character is used in the URL pattern, it may bypass these protections and grant unauthorized access to resources. The application might interpret the wildcard as a placeholder for any resource identifier, allowing attackers to retrieve or manipulate data beyond their authorized scope.

Let's consider a REST API that has the following endpoint:

/api/v1/users/{user_id}: Retrieves user information based on the specified user_id.

Suppose an attacker discovers that the API also responds to the wildcard pattern /api/v1/users/*. By requesting /api/v1/users/*, the attacker can potentially bypass the authorization checks associated with the specific user ID. The application might interpret the wildcard as a valid placeholder, returning information for all users or a broader range of data.

v. Adding .json to the endpoint

Many web applications allows clients to request data in different formats such as JSON, XML, or HTML. By appending ".json" to the endpoint, the client explicitly specifies the desired response format as JSON. This can impact how the application processes and authorizes the request, potentially bypassing certain protections or access controls or In some cases, the application might treat requests with different file extensions (like ".json") differently from requests without them. While the /api/v1/users/1234 endpoint may require additional authorization or ownership checks, the /api/v1/users/1234.json endpoint might not enforce the same level of protection and in some cases the application may mistakenly assume that the addition of ".json" indicates a request for public or non-sensitive data, allowing unauthorized access to resources or revealing information that should be protected.

Example: Consider a web application that uses the following endpoints:

/api/v1/users/{user_id}: Requires proper authorization and authentication for accessing user data. Returns a 401 Unauthorized status code if the user is not authorized.

/api/v1/users/{user_id}.json: Presumes that the ".json" extension indicates a request for public data. Returns a 200 OK status code and provides user data in JSON format, regardless of the user's authorization status.

It's important to note that the behavior of applications regarding file extensions may vary. Some applications may implement proper access controls and enforce authorization checks consistently regardless of the presence of file extensions.

vi. Test on outdated API versions

Outdated API versions may have weaker or non-existent authorization checks compared to newer versions. This can occur due to changes in the implementation over time or improvements made to address security vulnerabilities. By targeting an older version that lacks stringent authorization checks, an attacker may be able to exploit IDOR vulnerabilities and access resources without proper authorization. Example: Let's consider a scenario where an API has two versions, v1 and v2, and the /api/user/{user_id} endpoint is involved:

/api/v2/user/{user_id}: Represents the updated version of the API. Proper authorization and authentication are required to access user data. Returns a 401 Unauthorized status code if the user is not authorized.

/api/v1/user/{user_id}: Represents an outdated version of the API. The implementation lacks certain authorization checks or has weaker security controls. Regardless of the user's authorization status, it returns a 200 OK status code and provides user data.

In this scenario, an attacker can target the outdated v1 version (/api/v1/user/1234) to potentially exploit IDOR vulnerabilities. By doing so, they can bypass the stricter authorization checks enforced in the updated v2 version (/api/v2/user/1234).

vii. Case Change

Some web servers or applications may handle URLs in a case-sensitive manner. In such cases, changing the case of a part in the URL can lead to different outcomes or bypass certain protections. If the application is not properly handling case sensitivity, an attacker can exploit this inconsistency to gain unauthorized access or manipulate resources. Moreover in situations where access controls are based on case-sensitive parameters, changing the case of those parameters can potentially bypass the intended restrictions. By modifying the case, an attacker can attempt to access resources that should be protected, exploiting vulnerabilities stemming from inconsistent or flawed case-sensitive access controls.

Example:

Let's consider an example where a web application has the following endpoints:

/admin/profile: Allows administrators to access their profile information. /user/profile: Allows regular users to access their profile information.

Suppose the application enforces access controls based on the case-sensitive /admin/profile endpoint, granting administrators access to sensitive profile data. Regular users, on the other hand, are restricted to the /user/profile endpoint.

By changing the case of the URL from /admin/profile to /ADMIN/profile, an attacker can attempt to bypass the intended access controls. If the application does not handle URL cases consistently, it may interpret the modified URL as a valid request, potentially granting unauthorized access to the administrator's profile data.

viii. Leaked IDs

In certain scenarios, we may come across a distinct IDOR vulnerability that appears to be unexploitable due to the length and non-guessable nature of the UUID. However, it is crucial not to abandon such cases, as there is still a possibility that the application inadvertently leaks IDs through responses, other API endpoints, waybackurls, or other publicly accessible pages within the application.

Consider the example:

There is a referral functionality on the website that permits users to refer others and receive points in return. The referral URL follows the format https://something.com/refer?user_id=O1SUR7GJ43HS93VAR8x4w89. The problem lies in the length of the user_id, which makes it impractical to guess or enumerate. However, during the investigation using waybackurls, it was discovered that multiple referral URLs were leaked, providing access to numerous user IDs. This information becomes instrumental in exploiting the vulnerability.

Preventive Measures

Applications can employ various methods to prevent IDOR vulnerabilities. The application can verify the user's identity and permissions before granting access to a resource. For instance, it can validate if the user's session cookies correspond to the user_id associated with the requested messages.

Websites can also utilize unique and unpredictable keys or hashed identifiers to reference each user's resources. Hashing involves a one-way process that transforms a value into a different string. By securely hashing IDs using a robust algorithm and a secret key, it becomes challenging for attackers to guess the hashed ID strings.

To effectively mitigate IDOR risks, it is crucial to implement robust access controls, diligently validate user input, utilize secure indirect access controls, adopt random and resilient identifiers, and regularly conduct security assessments and testing.