IDOR - A Detailed Explanation with Explanation and Mitigation

on

 In the world of web security, Insecure Direct Object Reference (IDOR) is a common and critical vulnerability that can lead to unauthorized access to sensitive data. In this article. We will delve into what IDOR is, how it works, the problems it can cause, and how it can be mitigated.

What is IDOR?

IDOR stands for Insecure Direct Object Reference and is a type of access control vulnerability. IDOR provides direct access to objects such as files or rows from a database that shouldn't be accessible. This can lead to the bypass of authorization mechanisms via the modification of values that have no further validation applied.

This type of vulnerability can occur when a web server receives user-supplied input to retrieve objects (files, data, documents), too much trust has been placed on the input data, and it is not validated on the server-side to confirm the requested object belongs to the user requesting it.

Example scenario

Imagine you have a web application for an online banking system. Users can view their account details by accessing a URL like this:

https://bankingapp.com/account/12345

Here, 12345 is the account number, which is a direct reference to the user's account in the database.

Exploiting IDOR

  1. Normal User Behavior: A legitimate user logs in and accesses their account details using the URL https://bankingapp.com/account/12345. The application retrieves and displays the account information for account number 12345.
  2. Attacker's Action: An attacker logs into their own account and notices the URL structure. They decide to experiment by changing the account number in the URL to 12346: https://bankingapp.com/account/12346
  3. Unauthorized Access: If the application does not have proper access controls in place, it will fetch and display the account details for account number 12346, which belongs to another user. The attacker now has unauthorized access to another user's account information.

IDOR vulnerabilities can be categorized as:

  • Horizontal IDOR: When a user can access data of another user with the same privilege level.
  • Vertical IDOR: When a user can access data that requires higher privileges.
  • Object-level IDOR: When a user can alter or delete objects they shouldn't have rights to.
  • Function-level IDOR: When a user can access functions or actions they shouldn't be able to

Types of IDOR

  •         IDORs that directly reference database objects

Think of a website using the URL mentioned below to get to the customer account page. It pulls data from the backend database, as is evident.

 

https://www.examplewebpage.com/customer_account?customer_number=132355

 

Here, the customer number is specifically employed as a record index in queries against the backend database. A malicious party can readily alter the customer_number value if no other restrictions exist. This would let the perpetrator evade access controls and look at customer records.

This form of IDOR culminates in the horizontal escalation of privileges. In addition to horizontal privilege escalation, an intruder may be able to execute vertical privilege escalation by switching the user to one with more privileges. Once an infiltrator has landed on a user’s account page, other potential outcomes are password leaks or parameter modification.

  • IDORs that directly reference static files

Imagine you have a web application that allows users to download their chat transcripts. The transcripts are saved as static files on the server with filenames that increment based on the order they were created. Users can access their transcripts using a URL like this:

https://chatapp.com/transcripts/12345.txt

Here, 12345.txt is the filename of the chat transcript, which is a direct reference to the file stored on the server.

Exploitation:

Normal User Behavior: A legitimate user logs in and accesses their chat transcript using the URL https://chatapp.com/transcripts/12345.txt. The application retrieves and displays the transcript for file 12345.txt.

Attacker's Action: An attacker logs into their own account and notices the URL structure. They decide to experiment by changing the filename in the URL to 12346.txt:

https://chatapp.com/transcripts/12346.txt

Unauthorized Access: If the application does not have proper access controls in place, it will fetch and display the chat transcript for file 12346.txt, which might belong to another user. The attacker now has unauthorized access to another user's chat transcript.

  • IDORs in POST body instead of URL

Imagine you have a web application that allows users to update their profile information. The profile update form includes a hidden field for the user ID, which is sent in the POST body when the form is submitted.

Here’s what the form might look like:

<form action="/update_profile" method="post">

  <!-- Other fields for updating name, email, etc. -->

  <input type="hidden" name="user_id" value="12345">

  <button type="submit">Update Profile</button>

</form>

Exploitation

Normal User Behavior: A legitimate user logs in and updates their profile information using the form. The form submission sends a POST request with the user ID in the body:

POST /update_profile HTTP/1.1

Host: examplewebsite.com

Content-Type: application/x-www-form-urlencoded

user_id=12345&name=John&email=john@examplewebsite.com

Attacker's Action: An attacker logs into their own account and intercepts the POST request using a tool like Burp Suite. They notice the user_id field in the POST body and decide to change it to 12346:

POST /update_profile HTTP/1.1

Host: examplewebsite.com

Content-Type: application/x-www-form-urlencoded

user_id=12346&name=Attacker&email=attacker@examplewebsite.com

Unauthorized Access: If the application does not have proper access controls in place, it will update the profile information for user ID 12346, which belongs to another user. The attacker now has unauthorized access to modify another user's profile.

  • Path traversal

Path traversal, also called directory traversal, is a unique type of IDOR vulnerability that an attacker leverages to access or manipulate files or folders directly on the server that runs the web application. This is a level deeper than other types of IDOR attacks because it allows direct access to file system resources instead of database records. Path traversal can allow an attacker to access configuration files, discover user credentials, or even obtain a fully functional shell on the target.

https://www.examplewebpage.com/display_file.php?../../../etc/passwd\

  • IDORs  that provide access to cookies

This category of IDOR allows attackers to steal user data. These cookies may contain their stored passwords and other private information. The only thing the perpetrator must do is change the cookie’s ID in the URL.

http://www.examplewebpage.com/cookieid=001291971

 

IDOR Mitigation: 

Insecure Direct Object Reference (IDOR) vulnerabilities can be mitigated through several best practices and security measures:


Access Control Checks: Implement strict access control checks for each object that users try to access. Ensure that the application verifies whether the user has permission to access the requested resource.

Indirect References: Use indirect references instead of direct object references. Replace IDs, names, and keys in URLs with cryptographically strong, random values like UUIDs or GUIDs.

Input Validation: Validate and sanitize all user inputs to prevent unauthorized access. Ensure that user inputs are checked against a whitelist of allowed values.

Session Management: Use session information to determine the currently authenticated user and their permissions. Avoid exposing identifiers in URLs and POST bodies.

Code Reviews and Automated Tools: Conduct regular code reviews and use automated tools to identify and remediate IDOR vulnerabilities. These tools can help detect insecure direct object references and other security issues.

Security by Design: Follow secure-by-design principles during the development process. Ensure that authentication and authorization checks are performed for every request that modifies, deletes, or accesses sensitive data.

Complex Identifiers: Use complex, non-enumerable identifiers to make it difficult for attackers to guess valid values. However, remember that access control checks are still essential even with complex identifiers.

This is all about IDOR. If you enjoyed this post and want to stay updated with more content like this, let's connect on LinkedIn! Follow us there for insights, updates, and more. Looking forward to connecting with you!


Comments

Post a Comment