IDOR: A Complete Guide to Advanced Exploitation of IDOR Vulnerabilities

This article discusses how to identify IDOR vulnerabilities and how they can be exploited. More complex cases will also be considered. Let's start with the definition of IDOR vulnerabilities.

What are IDOR vulnerabilities?

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

IDOR vulnerabilities are caused by a lack of access control. In other words, the web application or API does not check whether the requesting user is the legitimate owner of the data object. As a result, the vulnerable component returns the data object even if the user does not have permission to access it.

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

Identification of IDOR vulnerabilities

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

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

Novice bug hunters often hear that IDOR vulnerabilities are easy to find. However, after spending some time searching for such vulnerabilities, the opposite can be discovered.

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

Exploiting Basic IDOR Vulnerabilities

The main IDOR vulnerabilities are that we can easily change a predictable identifier, such as a numeric integer, 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 it can be as simple as changing identifiers, but it can also be more complex.

Let's consider some more complex cases…

Exploiting IDOR vulnerabilities through parameter pollution

When testing, all possible exploitation methods should be considered. Parameter pollution 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 method that helps bypass certain checks, such as authorization checks.

Using IDOR with JSON globbing

Similarly, as above, we need to try several different methods to attempt 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 can achieve undesirable behavior by replacing our identifier with:

• array of identifiers: [1234, 1235]

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

• wildcard character, such as an asterisk (*) or a percent sign (%) (again, be careful when testing)

• large integer value by adding zeros before our identifier: 00001235

• negative identifier: -1

• decimal number: 1235.0

• string value with added delimiter: “1234,1235”

Exploitation of IDOR through request method

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

Let's look at a small example that will 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 is only accessible by changing our request method to POST. This would allow us to extract sensitive data of any user without obtaining permission to do so.

To successfully exploit this case, we could simply send a POST request as shown below:

Exploitation of IDOR through content type

Just like in the previous case, it is possible that the request is processed differently by the underlying framework or library and allows state-changing actions or extracting confidential data again by simply setting a different content type header.

Exploitation of outdated API versions

Targets providing their public API often use a versioning system. 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, for example, extracting confidential data from the API even if the latest version has already addressed this security issue.

Exploitation of IDOR using static keywords

Sometimes developers use keywords like "current" or "me" to refer to the current user. You can try replacing such keywords with a numeric identifier and retest the IDOR vulnerability.

Exploitation of IDOR using unpredictable identifiers

More and more developers are starting to use UUIDs or other unpredictable hashes simply because they are hard to guess and not susceptible to brute force attacks. However, there is still hope, as there are several ways we can leverage to enumerate these identifiers.

One way is to request another endpoint to return any links with the identifiers we are looking for.

And there are several other ways to find links to IDs, such as:

• public profiles (e.g., profile pictures)

• login/registration and password reset forms

• in-app sharing links

• email unsubscribe forms

• in-app messages

• Wayback Machine

• search engines (e.g., Google and Bing)

Exploitation of Secondary IDOR Vulnerabilities

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

Second-order IDOR vulnerabilities are more complex and harder to detect. An example could be a scheduled data export feature. First, a schedule is created where the user ID is saved in an external scheduling service. When the schedule is triggered, it later retrieves your user ID from the metadata to create the export. This second step often does not undergo any additional access control checks. We can exploit this vulnerable behavior and instead attempt to generate a data export of our second test account.

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 detected with experience. They are generally highly dangerous and often come with large rewards in bug bounty systems.

Now that you have learned about complex IDOR vulnerabilities, it's time to put your knowledge into practice!