How to Find: Insecure Direct Object References (IDOR)

What is an insecure direct object reference (IDOR)?

IDOR is a broken access control vulnerability in which invalidated user input can be used to perform unauthorized access to application functions. This can result in sensitive information disclosure, information tampering, etc. 

This issue was previously part of OWASP's top 10 vulnerabilities; later, it was merged with OWASP's top 10 A5 broken access control vulnerability. 

For proper exploitation of the vulnerability, IDOR is usually paired with a broken access control vulnerability, as the access control issue allows an attacker to directly access the object. IDOR occurs in HTTP methods like GET, POST, PUT, and DELETE. 

For example, consider a hospital application with a patient ID in the following pattern:

PID001

PID002

PID003

Suppose this application contains a service that exposes patient information based on the Patient ID. An attacker can exploit it by generating a list of Patient IDs from POD001 to PID999. If the access control mechanism is not properly implemented, a malicious user can view, alter, or delete the information of other patients.

Sample POC

Many variables, such as "id," "pid," and "uid," can be found in an application. These values can be found in headers and cookies and passed as parameters; by modifying this ID to that of another user, an attacker can view, edit, or delete the specific data.

One of the main reasons IDOR is common in an application is that it cannot be detected by tools alone. IDOR requires manual security testing and creativity to identify them. Some tools can be used to detect it, but the user must analyze and evaluate it.

How to detect IDOR?

The test scenario is as follows:

1. Enumerate the user's identifiers, such as UID and ID, within the application.
2. Authenticate to the web application using a particular user.
3. Start Burp interception and capture all of the application's requests.
4. Using the repeater module, replay the intercepted request with modified parameters such as UID and ID that could point to other users' data.
5. If the identifier value is hashed, you can use several decoding techniques to bypass it.

Test cases for IDOR

To test IDOR, the researcher has to identify all locations in the application where the user input is used to refer to objects directly, such as user input to fetch user data from the database and user input to access files. The following are a few test cases for IDORS:

1. Input parameter used to retrieve database records

Consider the above example for patient health records. For example, suppose there is an API https://example.com/api/patient-data?id=pid001 that is used to fetch patient data from a database. The user input is directly taken to fetch the data from the database. Since the value of PID goes directly to the query, modifying the parameter makes it possible to retrieve any patient information from the database.

2. Input parameter used to retrieve a file system resource

Consider the above example for patient health records. For example, suppose there is an API https://example.com/api/patient-license?id=pid001.pdf used to fetch a patient's driving license within the system. The user input is directly taken to fetch the file within the system. Modifying the pid parameter makes it possible to retrieve any patient's driving license within the file system.

3. Input parameter used to perform a particular operation

Consider the above example for patient health records. Suppose there is an API https://example.com/api/modify-patient-data that takes a patient's ID as a parameter and performs operations such as modifying patient data. The user input is directly taken to perform the operation. Modifying the PID parameter makes performing operations on other user data possible.

Good Read: All You Need to Know About OWASP ASVS 4.0

How to prevent IDOR vulnerabilities? (Best practices)

1. Implement a proper access control mechanism.
2. Avoid displaying private object references, such as keys.
3. Use a "accept known good" method to validate any private object references thoroughly.
4. Verify all referenced objects' authorization.
5. Implement proper parameter validation.
6. Avoid using sequential UUIDs.
7. Ensure that access tokens are mapped to users so that they can only access/modify their account information.

What's the impact of IDOR?

The impact of IDOR is difficult to predict because it depends on the type of operation an attacker can perform on the data. Unauthorized information disclosure, data manipulation, and access to features not intended for users are only a few of them.

What's a blind IDOR?

Blind IDOR attacks are similar to Blind XSS or SQLi attacks in that the specific IDOR request is undetectable because the response does not reveal the vulnerability. One example of such a scenario is an application that sends user information as a mail once the user updates their profile but does not expose anything in the response.

Useful tools

IDOR testing can also be automated by using Burp Suite plugins such as “Authz”, “AuthMatrix” and “Authorize”.

Conclusion

Despite being one of the most straightforward vulnerabilities to detect, IDOR is one of the most common vulnerabilities in applications. IDOR not only causes horizontal privilege escalation but may also result in vertical privilege escalation.

One of the key reasons IDOR is common in applications is that it is difficult to detect with tools alone. Some tools can detect it, but the user must examine and assess it. This vulnerability can go undiscovered in traditional penetration tests unless a pentester tests every possible parameter in every request endpoint.