Insecure Direct Object References (IDOR)
CWE-639: Authorization Bypass Through User-Controlled Key
Understanding Insecure Direct Object References (IDOR)
What is IDOR?
Insecure Direct Object References (IDOR) occur when an application uses user-supplied input to access objects directly without proper access control checks. This vulnerability can lead to unauthorized access to data or functions, enabling attacks such as horizontal and vertical privilege escalation.
How IDOR Occurs
IDOR vulnerabilities typically arise when the application fails to verify if a user is authorized to access or manipulate an object. These vulnerabilities are most commonly associated with horizontal privilege escalation (accessing data of other users at the same privilege level) but can also involve vertical privilege escalation (accessing data or functions reserved for higher privilege levels).
6. C#/.NET Example (ASP.NET MVC)
Scenario: An ASP.NET MVC application allows users to view their orders by passing an order ID in the query string.
Vulnerable Code:
Explanation:
The application directly uses the
orderId
parameter to retrieve order information.An attacker can modify the
orderId
in the query string to view orders belonging to other users.
Checklist for Testing IDOR Vulnerabilities
1. Identify User-Controlled Parameters
Review URLs, POST bodies, headers, and cookies for parameters that reference objects (e.g.,
user_id
,file_id
, etc.).Look for identifiers exposed in client-side code or API responses.
2. Test Parameter Manipulation
Attempt to change the parameter value to that of another user’s ID or object reference.
Observe if unauthorized data or functions are exposed.
3. Examine API Endpoints
Review RESTful API endpoints for object references in URLs or request bodies.
Test different object IDs in API requests to see if unauthorized data is returned.
4. Test with Different User Roles
Use accounts with different privilege levels (e.g., admin, regular user, guest) to test if object references can be used to escalate privileges.``
Pro Tip:
Identify Authentication Methods: Make sure to capture the session cookie, authorization header, or any other form of authentication used in requests.
Use Auth-Analyzer in Burp Suite: Pass these authentication tokens to the Auth-Analyzer Burp extension. This tool will replay all requests with the captured session information.
Test with Another User: Log in as a different user and activate the Auth-Analyzer extension. If you see the
SAME
tag in the extension results, this could indicate an IDOR vulnerability.Manual Verification: Always manually check the request to confirm whether the vulnerability is genuine.
Assess ID Predictability: Determine if the IDs are predictable. If they aren't, investigate where they might be leaked, such as in other API responses. This could help in further exploitation or verification of the vulnerability.
UUID/GUID
UUID (Universally Unique Identifier) or GUID (Globally Unique Identifier) is a 128-bit number used to uniquely identify information in computer systems. They are widely used in databases, software development, and distributed systems to ensure that identifiers are unique across different systems and times.
UUIDs are typically represented as a series of hexadecimal digits, often split into five groups, separated by hyphens. For example: 123e4567-e89b-12d3-a456-426614174000
.
Types of UUID
Tools for decoding and analyzing UUIDs
The version and variant are encoding within UUIDs.
Version Digit ("M")
Variant digit ("N")
Nil UUID – Version 0
Usually used for fixed UUIDs like for testing accounts and default credentials,.............
Time-based UUID – Version 1
this kind of UUIDs is time and node based and the Clock part is usually random
As you might expect, relying on UUID v1 for sensitive actions is inherently insecure. In this video, a scenario is demonstrated where an application uses UUID v1 as a token for password resets. An attacker can easily extract other users' UUIDs (eg. from creating account or API calls), determine the timestamp, and either manually generate valid password reset tokens or brute-force the clock component.
DCE Security UUID – Version 2
Name-based UUID - Version 3 and 5
Randomly Generated GUID - Version 4
Hacking Unpredictable IDORs
Unpredictable IDs may seem secure, but there are various ways they can still be found:
Interestingly, the application used some fixed UUIDs like 00000000-0000-0000-0000-000000000000 and 11111111-1111-1111-1111-111111111111 for some _administrative_ users
Code Examples
1. PHP Example
2. JavaScript/Node.js Example
3. Python/Flask Example
Prevention Techniques
Always verify that the user is authorized to access or modify the object.
Use session or JWT tokens to determine the current user instead of relying on user-controlled parameters.
Avoid Exposing Identifiers in URLs
Resources
Last updated