All About IDOR Attacks
How attackers use Insecure Direct Object References to access data illegally
Have you ever wondered how data breaches happen?
Nowadays, it seems like a new company is breached every five minutes. But how exactly do these breaches happen? How do hackers get their hands on sensitive data? In this article, we’ll talk about a simple yet very impactful vulnerability that attackers often use to gain access to confidential data: IDOR.
What Is IDOR?
IDOR stands for “Insecure Direct Object Reference.” Despite the long and intimidating name, IDOR is actually a straightforward vulnerability to understand. Essentially, IDOR is missing access control.
Let’s say example.com is a social media site that allows you to chat with other users. And when you signed up, you noticed that your user ID on the website is 1234. This website has a page that allows you to view all your messages with your friends. When you click on the “View Your Messages” button located on the homepage, you get redirected to this URL, where you can see all your chat messages with your friends on the website:
Now, what if you change the URL in the URL bar to this one?
You notice that you can now see all the private messages between another user, user 1233, and all their friends. What just happened? At this point, you have found an IDOR vulnerability.
You were able to see the messages of user 1233 because there is no identity check in place before the server returns the private info of users. The server was not verifying that you were, in fact, user 1233, or if you are an imposter. It simply returned the information, as you asked.
IDORs happen when access control is not properly implemented and when the references to data objects (like a file or a database entry) are predictable. In this case, it was easy to infer that you can retrieve the messages for users 1232 and user 1231 by accessing these URLs:
If the website were to use a unique, unpredictable key for each user, the website would not be vulnerable because there would be no way for an attacker to guess the value of user_key:
Instead, the social media site implemented an insecure and direct object reference. These predictable “Direct Object References” expose the data hidden behind them to the internet, allowing anyone to grab the referenced information.
Implications of IDOR
As you can probably imagine, IDORs can be quite catastrophic for businesses. In this case, think about all the bad PR example.com will face when its users find out that anyone could have read their private messages!
This vulnerability could be exploited even more aggressively: Attackers could write a script to query all user IDs and scrape all of the data automatically! If this vulnerability happens on an online shopping site, attackers might be able to harvest millions of bank accounts, credit card numbers, and addresses!
IDORs are not just limited to reading other users’ information either. They can also be used to edit data on another user’s behalf. Let’s say you can change your own password on example.com by going to this URL:
There is an IDOR on this page and you can change the password of user number 1233 if you visit this URL:
This means that you could take over any user's account on the platform by changing their password without their consent! IDORs on critical functionalities such as password reset, password change, and account recovery are critical vulnerabilities that compromise the entire web application.
IDORs are common because they are hard to detect, so the best way to prevent IDORs is to implement protections during the development process.
For an IDOR vulnerability to be exploitable, there must be a direct object reference to the data object and a lack of access control. So to prevent IDORs, you can either:
- Avoid direct object references.
- Implement detailed access control for each application resource.
First, you can refer to resources using indirect object references instead. For example, applications can map user-provided IDs to another object ID on the back end based on the user’s session. For example, let’s say that your site has a file upload functionality and users should only access their own uploads. If you use a direct reference in the URL like this:
Attackers can read others’ files by manipulating the file ID parameter like this.
On the other hand, If you let the user specify a file index:
And then map to the real file ID in the backend, users cannot control the entire file ID, and cannot manipulate URL parameters to access others’ files.
Real file ID: username-uploads-3
You can also use an unpredictable hash or random string to refer to objects instead of using a simple numerical ID. This makes it more difficult or even impossible to enumerate real data IDs and harvest sensitive data.
But the root cause of IDOR vulnerabilities is missing access control. If you can check the user’s permissions before returning sensitive resources, direct object references wouldn’t be such a problem after all. So the second thing you should do to prevent IDORs is to implement robust access control. For each piece of application resource that should be restricted, you should verify that the user is indeed authorized to access it.
Is there a way to find IDOR vulnerabilities that are already out there haunting your application? Automatic vulnerability scanners are pretty bad at finding IDORs because they cannot recognize which resources require which kind of protection. So the best way to discover existing IDORs is through a source code review to see if all direct or indirect object references are protected by proper access control.
Finally, manual testing is also an effective way of testing for IDOR. When manual testing, you should create two different accounts and see if you can access the first account's info using the second account. And remember that IDORs can appear in URL parameters, form field parameters, file paths, headers, cookies, and so on. So you can check for IDORs by capturing and inspecting each request that should be restricted, alter these fields that refer to resources, and try to hack one of your accounts from the other.
IDORs are a dangerous vulnerability that can threaten your users' privacy and the integrity of your application. But they can be reliably prevented by implementing indirect object references and robust access control.
That’s it for today’s security lesson. Thanks for reading!