Insecure Direct Object Reference (IDOR)

Type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. The term IDOR was popularized by its appearance in the OWASP 2007 Top Ten.

Alternative name is Authorization Bypass.

Related Concepts:

• Authentication

• Authorization

• Privilege Escalation#Horizontal privilege escalation

Shutterstock

Explore

Core Principles

Authorization cannot happen before authentication.

If the application doesn't know who you are, it cannot verify what permissions your user has. If an IDOR doesn't require you to authenticate (login or provide session information), you must fix authentication first before fixing the authorization issue.

Technical Mechanism (The "Why")

• The Flawed Query: The vulnerability exists because the database query looks for the object ID but ignores the user ID.

  • Vulnerable SQL Example:

    SELECT person, address, status FROM Packages WHERE packageID = value;

  • Secure Logic: The query should be: WHERE packageID = value AND ownerID = currentUser

• Session Management:

  • Authentication isn't just a one-time login; it relies on Session Information (cookies/tokens).

  • The application must validate this session info against the requested Object ID on every request.

IDOR Variations (The "Disguises")

Practical Discovery Techniques

Where to Look

• URL Parameters: Look for IDs in the address bar (e.g., ?packageID=1001).

• AJAX/API Requests: Use browser Developer Tools (Network Tab) to spot background requests (e.g., view_accountinfo) that might pass user IDs not visible in the URL.

• Local Storage: Sometimes IDs are stored client-side in the browser's Storage Tab (e.g., auth_user data entries).

Essential Tools

• UUID Decoder: checks if an ID is UUID v1.

  • Mechanism: UUID v1 consists of the host MAC address + current timestamp.

  • Vulnerability: Since the MAC is static and time is linear, randomness is an illusion.

• Hash Identifier: Helps identify if a random string is MD5, SHA1, etc., allowing for potential rainbow-table attacks.

• Burp Suite / Zap: For capturing and modifying requests (Repeater).

UUID Prediction Math

If the app uses UUID v1, and you know the generation time window (e.g., "between 20:00 - 21:00"), you can generate all possible UUIDs for that range.

• Math: $60\text{ minutes}\times 60\text{ seconds}=3,600$ seeds to brute force.

Testing Workflow (Iterate & Observe)

1. Capture: Inspect HTTP requests (GET, POST, PUT, DELETE).

2. Identify: Locate parameters that look like references (id, user, account, file).

3. Decode: If the value looks complex, try Base64 decoding or Hash Identification.

4. Alter:

   • Increment/Decrement numbers.

   • Swap UUIDs with another user's UUID (if known).

   • Pollute parameters (e.g., change ?id=10 to ?id=10&id=11).

5. Observe: Did the server return data? Did it return different data?

Mitigation (How to Fix)

• Mandatory Access Control: Do not rely on hiding IDs. The server must check: "Does the logged-in user have permission to view this specific object?"

• Indirect Object References (Map Approach): Instead of exposing the database Key (e.g., 1001) to the user, use a temporary session-based map.

  • Example: User asks for package #1.

  • Server Map: User's #1 $\to$ Database ID #1001.

• Unpredictable IDs: Use UUID v4 (completely random) instead of sequential numbers or UUID v1.

  • Note: Random IDs are a defense-in-depth measure, not a replacement for access checks.

• Logging: Monitor for failed access attempts (e.g., User A trying to access User B's data multiple times).