Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference (IDOR) is a type of access control vulnerability that occurs when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.

---

What is an IDOR?

IDOR stands for Insecure Direct Object Reference and is a type of access control vulnerability.

This vulnerability can occur when a web server relies too heavily on user-supplied input to access objects (e.g., files, data, or documents). If the input is not properly validated on the server side to confirm the user has permission to access the requested object, an attacker can manipulate the input to access unauthorized data.

---

Practical Example of an IDOR

Consider the following scenario:

You are logged into a web application, and you access your own profile at the following URL:

https://example.com/user/profile?id=123

If you manually change the id=123 parameter to another user’s ID (e.g., id=124), and the application does not validate whether you are authorized to access that profile, you will see another user’s information. This is a classic IDOR vulnerability.

Common Techniques to Identify IDOR

Encoded IDs

When passing data from page to page via POST data, query strings, or cookies, developers often encode raw data to ensure compatibility with the web server. For instance, Base64 encoding is a common technique that can be easy to spot.

Example:

Encoded: MTIz
Decoded: 123

You can decode and manipulate encoded data using tools like https://www.base64decode.org/. After editing, re-encode it with https://www.base64encode.org/ and resubmit the request to see if the server accepts it.

Hashed IDs

Hashed IDs are more complex, but they may follow predictable patterns. For example, if IDs are hashed with MD5, the number 123 might become 202cb962ac59075b964b07152d234b70. Use hash-cracking tools like https://crackstation.net/ to reverse common hashes.

Unpredictable IDs

If IDs cannot be guessed or decoded, an effective method for detection is to create two accounts and swap their IDs. If you can view another user’s data while logged in with your account, you’ve found a valid IDOR vulnerability.

Where are they located?

The vulnerable endpoint you’re targeting may not always be something you see in the address bar. It could be content your browser loads in via an AJAX request or something that you find referenced in a JavaScript file. 

Sometimes endpoints could have an unreferenced parameter that may have been of some use during development and got pushed to production. For example, you may notice a call to /user/details displaying your user information (authenticated through your session). But through an attack known as parameter mining, you discover a parameter called user_id that you can use to display other users’ information, for example, /user/details?user_id=123.

How to Prevent IDOR Vulnerabilities

To mitigate IDOR vulnerabilities, implement the following measures:

• Use Proper Authorization Checks: Always validate user permissions on the server side for every request.
• Avoid Exposing Direct Object References: Replace sensitive IDs with indirect references like UUIDs.
• Implement Role-Based Access Control (RBAC): Enforce strict access controls based on user roles and permissions.
• Conduct Security Testing: Perform regular penetration tests and use automated tools to detect IDOR vulnerabilities.

Tools to Detect IDOR Vulnerabilities

Some tools to help identify and exploit IDOR vulnerabilities during testing:

• Burp Suite: Use tools like Repeater and Intruder to manipulate parameters and observe server responses.
• Postman: Test API endpoints for unauthorized access.
• OWASP ZAP: Automate security testing and parameter fuzzing.
• Fiddler: Monitor and manipulate HTTP/HTTPS traffic to test for IDOR.
• SQLMap: Detect and exploit IDOR vulnerabilities in SQL databases.

Common Mistakes Leading to IDOR

Here are some mistake you can avoid to prevent IDOR vulnerabilities:

1. Trusting User Input Too Much: Failing to validate or sanitize user-supplied input allows attackers to manipulate identifiers.

2. Overreliance on Client-Side Validation: Authorization checks performed only on the client side can be bypassed easily with tools like Burp Suite.

3. Exposing Sensitive Object References: Using sequential or predictable identifiers (e.g., integers) in URLs or API calls can make it easy for attackers to guess other IDs.

4. Not Implementing Access Control on All Endpoints: Developers might secure high-profile endpoints but leave less-obvious ones (e.g., AJAX requests or unused API parameters) exposed.

5. Hardcoding Authorization Logic: Embedding access control logic directly into application code instead of using a centralized and reusable access control mechanism increases the likelihood of mistakes.

By avoiding these mistakes and following secure coding practices, developers can significantly reduce the risk of IDOR vulnerabilities.

Some Practical Detection Techniques for IDOR

EHere are some techniques you can use to uncover IDOR vulnerabilities in your applications:

1. Parameter Enumeration: Enumerate sequential or predictable identifiers in URLs or POST data to check for unauthorized access.

2. Parameter Manipulation: Modify encoded or hashed identifiers in network requests and observe responses.

3. Session Swapping: Use two accounts simultaneously to test if you can access one account’s data while logged in with the other.

4. Inspect API Endpoints: Analyze the application’s API calls using tools like Burp Suite or browser developer tools to identify endpoints where IDOR might occur.

5. Fuzz Hidden Parameters: Use fuzzing tools (e.g., Burp Intruder, OWASP ZAP) to discover hidden or undocumented parameters that may be vulnerable.

If you combine these techniques with automated tools, it can help identify even subtle IDOR vulnerabilities.