Welcome back to the “Attacks You Should Know About” series! It’s been a while, but we’re coming back with one of the most prevalent vulnerabilities in web applications: Insecure Direct Object References, more commonly known as IDORs.

What is an IDOR?

An IDOR is a type of broken access control vulnerability found in web applications. It occurs when an application exposes a reference to an internal object and fails to verify whether the requesting user is authorized to access it. Objects can be any type of information that can be iterated through, including but not limited to file names, user data, financial records, and authentication identifiers (tokens, API keys, etc.).

Examples of IDOR

Let’s take a look at what an IDOR looks like at a basic level:

We can see in the URL that the user’s profile is directly referenced via the user ID 1234 in the backend database (often times this will be the primary key). If the application does not have proper controls in place, a threat actor can change the number (ex. 1235) and access other user profiles.

However, this is not the only format that you will see an IDOR in. Using the same example of referencing a user profile, here are a couple other concepts where the identifier is found in a different location:

URL Parameter

This can also be captured using a request interceptor like BurpSuite. Those requests will look like the examples below.

GET Request

POST Request

The common thread across these examples is that any time the client supplies an identifier to an object that can be modified by user-supplied input without the proper authorization check, you have a potential IDOR, regardless of where or what that identifier is.

IDOR – Direct Reference to Static Files

We’ll use a PortSwigger lab to showcase what finding an IDOR in the wild might look like. We start by navigating to the web application of interest and thoroughly investigating it for vulnerabilities. After searching for some time, we come across a live chat feature:

Furthermore, we see that there is an option to view a transcript of our chat history. Selecting “View Transcript” downloads the “2.txt” file.

Since our transcript starts with the cardinal number 2, it is implied that a “1.txt” file may also exist. We will now try intercepting the GET request when downloading the transcript and modifying the file name identifier to 1.

As we can see, we were successfully able to acquire the transcript for another user. Using the retrieved username, the threat actor would now have gained authenticated access to the application.

While this example only required iterating from 2 to 1, real-world applications may have hundreds, if not thousands, of files that can be iterated through. I highly recommend using a tool such as Burp Intruder to automate this process.

Mitigating IDORs

There are a handful of ways to mitigate IDORs, each depending on the nature of how the application is being developed. The ideal solution is to build the application so that objects are referenced indirectly. An example of doing this is by tying identifiers to user sessions. If direct object references are necessary, the straightforward solution is to require server-side authorization checks when attempting to access an object. This might be a query that checks for the data identifier and the user identifier:

Implementing more complex identifiers that don’t use sequential integers as GUIDs and UUIDs is a defense-in-depth measure that makes it harder for an attacker to enumerate data. A UUID like a3f8c2d1-7b4e-4f9a-b012-3c5e6d8f0a1b can’t be systematically guessed or incremented.

Note: this is not a substitute for proper authorization checks, but it raises the bar for attackers significantly. I recommend reading the OWASP cheat sheet on IDOR Prevention, as they showcase an example of mitigating this in Ruby on Rails.

Next time, we’ll continue exploring broken access control examples. Until next time, happy hacking!

Warning: Please do not try these tactics and techniques on any domain without explicit permission from the domain owner. This information is provided solely for educational purposes, and Abricto Security is not responsible for any individuals who use these tactics and techniques in an unauthorized or malicious manner.