Insecure Direct Object Reference (IDOR) is a vulnerability that occurs when a user is able to view or manipulate unauthorized data. The issue here is that the developer failed to implement proper access controls when calling resources, allowing users to access other users’ data simply by changing a parameter.
Finding and Exploiting IDOR
IDOR is a favorite vulnerability for many security testers as it is often easy to find and can have a high impact depending on the context.
Identifying the Vulnerability
The vast majority of the time, you can spot this vulnerability by looking for a request which contains an identifier tied to your user, such as:
- User ID (e.g.,
userId=123) - Username
- Document ID (e.g.,
invoice_id=INV-005)
Some applications will use this ID to serve content based on the ID supplied. Under normal circumstances, you would only supply your user’s ID, so developers might forget to include authentication or authorization checks when retrieving this data. If that’s the case, attackers can supply other users’ IDs to retrieve data belonging to them.
Impact of IDOR
This could be anything from a user’s shipping address, credit card number, or email. Not only can you retrieve information, but sometimes you can exploit IDOR to send commands to the application, such as:
- Adding an admin account
- Changing a user’s email
- Removing a set of permissions
Consider an example with two API requests: one to set a user’s email and another to get a user’s email. If the back-end application uses the userId value supplied by the user when performing these actions without any other verification, an attacker could easily modify and retrieve any user’s email on the application simply by changing the userId.
Bypassing Complex IDs
Sometimes it is as easy as changing your user ID to another user’s ID (e.g., changing userId=10 to userId=11). However, what if you can’t easily guess the user ID, as shown in the request parameter below?
Looking at the user ID of 8f14e45fceea167a5a36dedd4bea2543, you might think it’s a random ID that’s impossible to guess, but that may not be the case. It’s common practice to hash user IDs before storing them in a database, so maybe that’s what’s happening here.
If you know the original user IDs are simple, sequential integers (like 7, 8, 9, 10, 11) that are being hashed, the attack becomes feasible.
For instance, if the ID for user 7 is the MD5 hash of the number 7, an attacker can take an MD5 Hash of a sequential number like “11” to generate a user ID for that user.
Example:
- MD5 Hash of “7” =
8f14e45fceea167a5a36dedd4bea2543(Example ID) - MD5 Hash of “11” =
6512bd43d9caa6e02c990b0a82652dca(Generated ID for user 11)
Now that an MD5 hash for the integer 11 is generated, this can be used to retrieve information from that person’s user account.
Since the original user ID is guessable and increments by one for every user, this attack could also be scripted to exploit every user on the application, significantly increasing its impact.
Summary and Conclusion
IDOR is all about abusing an application’s functionality to retrieve unauthorized information. It can be as easy as changing a user’s ID to someone else’s, though you may have to figure out a way to generate another user’s ID if it’s not easily guessable (e.g., by de-hashing or guessing sequential IDs). Once exploited, this vulnerability can be used to retrieve sensitive information of other users or issue commands as other users. That’s why this vulnerability is normally considered a high severity finding; it’s easy to find, easy to locate, and it normally has a high impact.
Learning how to exploit common web application vulnerabilities by hand is a must for any security professional. As a bug hunter, you want to pay close attention to the bugs that are most commonly found by other hunters. XSS is extremely popular and easy to exploit, and is often the most rewarded bug on platforms like HackerOne. You also need to know other basic vulnerabilities such as SQL Injection and IDOR as they are also frequently found in web applications and often lead to high severity findings.
There are a bunch of other OWASP vulnerabilities that you will want to learn so you can add them to your arsenal of techniques. The more vulnerabilities you know how to exploit, the better your chances of finding one, and as you progress, you will learn more. That being said, if you only know a few basic web vulnerabilities, you can still be wildly successful.
