IDOR Attacks

IDOR (Insecure Direct Object References) is a type of vulnerability in web applications where an attacker can manipulate input to access resources (e.g., files, database records, etc.) that they should not have access to. It happens when the system uses user-supplied input to directly reference objects, such as database entries or files, without proper authorization checks.

How IDOR Works

In an IDOR attack, an attacker exploits an insecure direct reference to an object (such as a user ID, document ID, or file ID) by modifying the input parameter that references the object. The application doesn't properly validate whether the attacker has permission to access the object, and as a result, the attacker may gain unauthorized access to sensitive information.

For example:

• A URL might look like this:

  arduino
   https://example.com/user-profile?user_id=123 

   

  If an attacker changes user_id=123 to user_id=124, they might be able to access the profile of another user if proper access control is not in place.

Common Examples of IDOR

1. URL-based IDOR:

   • A website uses parameters in the URL to reference specific resources, such as user profiles, documents, or orders.
   • If an attacker can change the parameter in the URL (like user_id=123) to another value (user_id=124), they may be able to access data that belongs to other users.

   Example:

   sql
   
   
    https://example.com/view-order?order_id=456 

   Changing the order_id to 457 might allow the attacker to view another user's order details.

2. File-based IDOR:

   • Applications that allow users to access files via direct references (like file paths or IDs) can be vulnerable if the system does not properly validate file access permissions.

   Example:

   arduino
   
   
    https://example.com/files/download?file_id=789 

   By changing the file_id, an attacker could gain access to files they are not authorized to view.

3. API-based IDOR:

   • In REST APIs, the attacker might alter the resource ID in a request to access another user's data or modify it.

   Example:

   bash
   
   
   GET /api/v1/users/123/orders

   An attacker might change the user ID 123 to 124 to access another user's orders.

How IDOR is Prevented

1. Access Control Checks:

   • Always implement robust authorization checks on the server side. Ensure that a user can only access objects that they are authorized to access, regardless of what is passed in the request.

2. Do Not Trust User Input:

   • Avoid using user-supplied input directly to reference sensitive objects. Always validate and sanitize any input used to access resources.

3. Use Indirect References:

   • Instead of exposing real object identifiers in URLs or API calls, consider using indirect references like tokens or UUIDs that cannot be easily guessed or manipulated.

4. Access Control Lists (ACLs):

   • Use role-based or attribute-based access control to determine what objects a user is allowed to access. Each request should be validated against these policies.

5. Logging and Monitoring:

   • Monitor unusual access patterns and flag any suspicious attempts to access resources outside of a user's usual scope of permission.

6. Error Handling:

   • Ensure that the application does not reveal too much information about unavailable or restricted resources in error messages. For instance, do not expose the existence of other users' records when an attacker tries to access them.