IDOR explained — OWASP Top 10 vulnerabilities

Hello ethical hackers and welcome to this new episode of the OWASP Top 10 vulnerabilities series. In this blog post, you will learn all aspects of the IDOR vulnerability. You will start with the basics and gradually build your knowledge. When you finish reading this article, you will have a solid understanding of IDOR. Besides, you will be ready to put your knowledge into practice in the IDOR tutorial.

What is IDOR?

IDOR stands for Insecure Direct Object Reference. Let me break that down for you. I will make key concepts in bold so that it’s easier for you to connect the dots and understand IDOR meaning.

Typically, every application has to manipulate resources. For instance, an e-commerce website will manipulate products, users, baskets, etc. Each resource instance will be called an object, and it is generally referenced by an ID. For example, user A will have ID1 and user B will have ID2. IDOR vulnerability targets a flaw in the way the application references these objects. In other words, any insecure or lack of validation can lead to a malicious user directly accessing unauthorized resources.

I tried to put all the keywords into place. Hopefully, this makes sense for you now. If it is not clear, don’t worry. The following sections will make it crystal clear.

IDOR falls into the OWASP Broken Access Control vulnerability category. This means that you will find most of the IDOR vulnerabilities after you authenticate to the application. However, it’s not always the case.

Behind the Name: IDORs in the OWASP Top 10

When compiling its list of top 10 web application vulnerabilities, OWASP (the Open Web Application Security Project) popularized the term “insecure direct object reference” as a collective name for vulnerabilities that allowed attackers to reference objects directly and thus gain unauthorized access to application resources. Vulnerable web applications expose a direct reference to an internal implementation object, for example a user ID, and then fail to run proper authorization checks to ensure that the current user is permitted to access a resource or operation.

To formalize the simple (and common) idea that you can access resources and operations by manually messing about with a URL or form parameter, the OWASP Top 10 for 2007 introduced the separate category A4 Insecure Direct Object Reference. In 2017, this class of vulnerabilities was merged into A5 Broken Access Control.

IDORs in Action

An insecure direct object reference vulnerability occurs when the following three conditions are met:

1. The application reveals a direct reference to an internal resource or operation.
2. The user is able to manipulate a URL or form parameter to modify the direct reference.
3. The application grants access to the internal object without checking if the user is authorized.

While all this looks very formal, it can also be very simple. Let’s say that an online store sends you an email with a personal one-time promo code for spending a certain amount in the store. It then processes a URL such as www.example.com/applydiscount?promocode=123 without checking if the current user actually qualifies for the specified promo discount. If you see this during checkout, you might be tempted to type in other promo codes to see what happens. If you change the promocode parameter value to, say, 120 or 125 and get a different discount, then congratulations! You’ve just exploited an IDOR vulnerability.

Another trivial IDOR example could be a user ID included in the URL, such as www.example.com/userinfo/73627. Without proper session management and access control, the site might allow you to enumerate user IDs of other users, potentially exposing confidential information.

IDOR Types

Whether through URLs or form parameters, applications can expose lots of internal implementation details. Some parameters, like the promo code above, might be used for direct financial benefit. Others might be used to extract sensitive data or escalate access privileges. Depending on the attack possibilities they offer, we can roughly divide IDOR vulnerabilities into four classes (though in practice, these will often overlap):

• Obtaining unauthorized data access: Exposed object references may reveal direct database IDs, allowing attackers to retrieve database records containing sensitive information. Database key names and values can also be used to prepare SQL injection payloads.
• Performing unauthorized operations: By manipulating unvalidated user ID values, command names, or API keys, attackers can execute unauthorized operations in the application. Examples could include forcing a password change to take over a user’s account, executing administrative commands to add users or escalate privileges, and getting access to paid-for or rate-limited application APIs or features.
• Manipulating application objects: Access to internal object references can allow unauthorized users to change the internal state and data of the application. As a result of this vulnerability, attackers might tamper with session variables, for example to alter data, elevate privileges, or access restricted functionality.
• Getting direct access to files: Typically combined with path traversal, this type of IDOR lets attackers manipulate file system resources. This could allow them to upload files, manipulate other users’ data, or download paid content for free.

Even though many IDORs are significant vulnerabilities in their own right, they are typically exploited in combination with other attack vectors.

Detecting IDORs

For any serious security researcher, seeing an exposed internal identifier is an immediate invitation to test IDOR vulnerabilities, especially as they are a solid source of bug bounty payouts. To identify a potentially insecure object reference, you need to have some idea of how a specific application or website works, how it processes HTTP requests, and what information it should and should not reveal in its HTTP responses. Especially for more advanced vulnerabilities that involve passing data through APIs, detecting IDORs can be tricky.

For practical examples of ways to test for IDORs, see the OWASP page on testing for insecure direct object references.

Impact

It is hard to say what the potential impact of IDOR as it depends on what kind of data the attacker can get a hold on. Because an IDOR is often very easy to exploit, means that it is very likely to be abused. Below you can find some write-ups that show how high of an impact IDOR can have.

Preventing IDOR Vulnerabilities

While they don’t address the root cause of IDOR vulnerabilities, there are a few ways to mitigate the risk posed by direct references. The first approach is to replace them with indirect object references that are then internally mapped to actual objects. This could mean using a temporary per-session reference map populated only with values valid for a specific user and associated with random, non-sequential keys.

Using secure hashes instead of actual object references is another way to make it harder for attackers to tamper with user-controllable values. See the OWASP IDOR Prevention Cheat Sheet for detailed recommendations on replacing direct identifiers with secure salted hashes.

Both these methods are effective at hiding internal implementation details but don’t address the underlying access control issue. A more robust approach to eliminating IDOR vulnerabilities is to ensure proper session management and object-level user access control checks. That way, even if a determined attacker manages to discover an internal object reference and manipulate it, they will not obtain unauthorized access.

If you enjoyed this story, please share to help others.