Insecure direct object reference

Insecure direct object reference (IDOR) is a type of access control vulnerability in digital security.

This can occur when a web application or application programming interface uses an identifier for direct access to an object in an internal database but does not check for access control or authentication. For example, if the request URL sent to a web site directly uses an easily enumerated unique identifier (such as http://foo.com/doc/1234), that can provide an exploit for unintended access to all records.

A directory traversal attack is considered a special case of a IDOR.

The vulnerability is of such significant concern that for many years it was listed as one of the Open Web Application Security Project’s (OWASP) Top 10 vulnerabilities.

Examples

In November 2020, the firm Silent Breach identified an IDOR vulnerability with the United States Department of Defense web site and privately reported it via the DOD's Vulnerability Disclosure Program. The bug was fixed by adding a user session mechanism to the account system, which would require authenticating on the site first.

It was reported that the Parler social networking service used sequential post IDs, and that this had enabled the scraping of terabytes of data from the service in January 2021. The researcher responsible for the project has said this was inaccurate.

References

Added with the help of ChatGpt-3

An Insecure Direct Object Reference (IDOR) is a security vulnerability that occurs when an application allows a user to manipulate or access sensitive resources or objects directly, bypassing any authorization or authentication mechanisms. In simpler terms, it's a flaw that occurs when an application fails to properly validate and control user access to its internal resources.

Here's a breakdown of how this vulnerability works:

   Resources/Object References: In many applications, there are internal resources or objects that users should not have direct access to, such as private documents, user profiles, financial records, or any other sensitive data.

   Lack of Proper Authorization: Properly designed applications implement access controls to ensure that users can only access the resources they are authorized to access. This involves using authentication to verify the user's identity and then authorization to determine what actions or resources they are allowed to interact with.

   Exploiting the Vulnerability: In an IDOR vulnerability, an attacker finds a way to manipulate the application's input parameters or URLs to directly access resources they shouldn't have access to. This can be done by modifying parameters, such as changing an ID number in a URL, to reference another user's data.

   Bypassing Access Controls: Since the application is not properly validating the user's authorization, the attacker can bypass the intended access controls and retrieve or modify sensitive information belonging to other users.

For example, consider an online bookstore application. Each user has a unique ID associated with their account. The application uses this ID to fetch a user's order history. If the application doesn't properly validate the user's identity and simply relies on the ID provided in the URL, an attacker could change the ID in the URL to access another user's order history.

To prevent IDOR vulnerabilities, developers should follow secure coding practices:

   Implement proper authorization mechanisms to ensure that users can only access the resources they are allowed to.
   Avoid exposing sensitive data or object references directly in URLs or input parameters.
   Validate user input and ensure that users can only access resources they have explicit permission for.
   Implement access controls at both the front-end and back-end levels.
   Use randomized or encrypted identifiers rather than sequential or easily guessable ones.

Regular security testing, code reviews, and vulnerability assessments can help identify and address IDOR vulnerabilities before they are exploited by malicious actors.