BLOG
Despite being one of the simplest vulnerabilities to detect, IDOR is one of the most common vulnerabilities found in applications. Here's how to prevent it
- Posted on: Jan 11, 2022
-
4 Mins Read
- Last updated on: Sep 10, 2024
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:
|
Request: |
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 this 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.
Detecting IDOR:
The test scenario is as follows:
1) Enumerate 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 Insecure Direct Object References (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, 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, by modifying the parameter it is 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, suppose there is an API https://example.com/api/patient-license?id=pid001.pdf that is used to fetch a patient's driving license within the system. The user input is directly taken to fetch the file within the system. By modifying the pid parameter it is possible to retrieve any patient driving license within the file system.
3) Input parameter used to perform 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. By modifying the PID parameter it is possible to perform operations on other user data.
Good Read: All You Need to Know About OWASP ASVS 4.0
IDOR Prevention:
1) Implement a proper access control mechanism2) Avoid displaying private object references such as keys
3) Use a "accept known good" method to thoroughly validate any private object references.
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 in such a way that they can only access/modify their own account information.
Impact:
The impact of IDOR is difficult to predict because it is dependent 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.
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”.
References: https://www.youtube.com/watch?v=3K1-a7dnA60
Conclusion:
Despite being one of the simplest vulnerabilities to detect, IDOR is one of the most common vulnerabilities found in applications. IDOR not only causes horizontal privilege escalation, but it 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 be used to 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.
