A Complete Guide to Advanced Exploitation of IDOR Vulnerabilities

IDOR (Insecure Direct Object Reference) vulnerabilities are one of the most common security vulnerabilities in modern web applications and APIs. It's no surprise that they are often recommended for new vulnerability hunters, as they are easy to discover and exploit, and are inherently high-severity vulnerabilities.

This article looks at how IDOR vulnerabilities can be identified and how they can be exploited. More complex cases will also be considered. Let's start by defining IDOR vulnerabilities.

What are IDOR vulnerabilities?

IDOR (insecure direct object reference) vulnerabilities occur when a web application or API uses user input to directly reference a data object. A data object can be anything from sensitive fields stored in a database to files residing in storage.

IDOR vulnerabilities are due to a lack of access verification. In other words, the web application or API does not check whether the requesting user is the rightful owner of the data object. This causes the affected component to return a data object even if the user does not have permission to do so.

Depending on the vulnerable component in the IDOR, vulnerabilities could lead to the disclosure of sensitive data or the introduction of unwanted changes, such as modification or deletion of fields in the database.

IDOR Vulnerability Identification

For a component, web application, or API to be vulnerable to IDOR attacks, a way to directly reference the object must be found. This is often done using a unique identifier. Although it is recommended that developers always use unpredictable identifiers as a best practice, there are still targets that do not follow these rules. Instead, they use predictable identifiers, such as numbers.

The component must perform an action that changes state or retrieve data that would not otherwise be publicly available. For example, the ability to view public blogs or comments is not considered an IDOR vulnerability.

New bug hunters often hear that IDOR vulnerabilities are easy to find. However, after spending some time searching for such vulnerabilities, you may discover the opposite.

The key is to improve content discovery methods and test features that have not yet been tested by others. For example, instead of testing the message sending feature, you should test the autosave feature or the component that marks a message as a draft.

Exploitation of basic IDOR vulnerabilities

The main vulnerabilities of IDOR are that we can easily change a predictable identifier such as a numeric integer value to another numeric identifier as shown in the example below:

In this case, the API endpoint would allow us to change the email address of our second test account. Sometimes this can be as simple as changing IDs, but it can be more complex.

Let's look at some more complex cases…

Exploiting IDOR vulnerabilities through parameter contamination

When testing, it is necessary to take into account all possible operating methods. Parameter contamination should also be tested. Depending on the technology used, the following scenarios are possible:

• both parameter values ​​will be combined,

• only the first value is processed,

• Only the last value is processed.

Parameter pollution is a known technique to bypass certain checks, such as authorization checks.

Using IDOR with JSON globbing

Likewise, as above, we need to try a few different methods to try to bypass any access control checks. If your target accepts a JSON body, we can play with different fields and see how the endpoint processes our input.

Again, depending on how our input is processed, we may achieve unwanted behavior by replacing our identifier with:

• array of identifiers: [1234, 1235]

• boolean value: true/false (be careful when testing)

• wildcard such as asterisk

• or a percent sign (%) (again, be careful when testing) a large integer value by adding zeros in front of our identifier:

• 00001235 negative identifier:

• -1 decimal number:

• 1235.0 string value with added delimiter:

“1234,1235”

Exploiting IDOR via Request Method

Sometimes, by simply changing the request method, our request is processed differently. If access control checks are missing, this could allow us to perform state modification actions or retrieve sensitive data on behalf of another user.

Let's look at a small example to help us better understand this type of IDOR:

As you can see in the code snippet above, 2 API endpoints are defined. Including a new one that lacks access control checks and can only be accessed by changing our request method to POST. This would allow us to extract sensitive data from any user without obtaining permission.

To use this case successfully, we could simply send a POST request like below:

Exploiting IDOR via Content Type

Just like the previous case, it is possible that the request is handled differently by the underlying framework or library and allows state change actions or sensitive data to be retrieved again by simply setting a different content type header.

Exploiting legacy API versions

Targets that expose their public API often use version control. Each new version often comes with new features as well as security fixes. If older versions are still available and lack access control checks, they may still allow sensitive data to be retrieved from an API, for example, even if the latest version has already addressed that security issue.

Exploiting IDOR Using Static Keywords

Sometimes developers use keywords like “current” or “me” to indicate the current user. You can try replacing such keywords with a numeric identifier and test the IDOR vulnerability again.

Exploiting IDORs using unpredictable identifiers

More and more developers are starting to use UUIDs or other unpredictable hashes simply because they are not easy to predict and are not susceptible to brute force attacks. However, there is still hope as there are several ways that we can use to our advantage to list these IDs.

One way is to ask another endpoint to return any links with the IDs we're looking for.

• And there are several other ways to find references to IDs, for example:

• public profiles (such as profile photos)

• login/registration and password reset forms

• links to share within the app

• email unsubscribe forms

• messages in the application

• Wayback Machine

search engines (eg Google and Bing)

Exploiting secondary IDOR vulnerabilities

Second-order IDORs are similar to IDOR vulnerabilities, but the only difference here is that the vulnerable component uses the input data to indirectly reference the data object. The ID is first stored and then retrieved for subsequent object reference.

Second-order IDOR vulnerabilities are more complex and harder to detect. An example is the function of exporting data on a schedule. First, a schedule is created and the user ID is stored in the external scheduling service. Once the schedule runs, it later extracts your user ID from the metadata to create an export. This second step often does not pass any additional access control checks. We can take advantage of this vulnerable behavior and try to generate an export of our second test account data instead.

There are several ways to do this, as we mentioned earlier in this article. In the following figure you can see a simple example of a second order IDOR vulnerability:

Conclusion

IDOR vulnerabilities can be easily discovered with experience. They tend to have a high degree of danger and are often accompanied by large rewards in bug bounty systems.