What is Null to Bug?
Null to Bug will be a series that explains bug types in a way of going from not knowing anything about a bug (null) to knowing how to find them (bug).
Insecure Direct Object References are my second favorite type of bug, behind application logic flaws, so I’ll start the series with this.
What is Insecure Direct Object Reference?
Insecure Direct Object References is a vulnerability in the broken access control category of OWASP Top 10. OWASP Top 10 is a list of the top ten web application security risk. To understand what an Insecure Direct Object Reference (IDOR) is, we have to understand what broken access control is and what a direct object reference is.
What is Access Control?
Before we understand the “broken” part of access control, we have to understand what access control itself is. Access control is the restricted access of resources (e.g. sensitive files or data). Say you wrote a secret on a piece of paper. You want this secret to only be accessed by you and your most trusted friend. To prevent others from accessing this secret, you lock it in a treasure chest and give yourself and your trusted friend a key to access it. Now only you and your friend has access to this secret, or at least, authorized access.
What is Broken Access Control?
Broken access control is when an attacker accesses resources that they don’t have permission to access. If I somehow find a way to read your secret in the treasure chest, that’s an example of broken access control.
What is Direct Object Reference?
According to OWASP, “A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory or database key. Without an access control check or protection, attackers can manipulate these references to access unauthorized data.”
You must be thinking, what’s an object and what does referencing an object mean? I’ll give an example.
www.socialwebsite.com/users/15/profile
Imagine the URL above shows your friend’s profile. Your friend’s ID is 15. This is an example of a direct object reference. Your friend is the object being referenced and the ID of 15 is doing the referencing. To reference a different object — to look at different user’s profile, you’d change 15 to 16.
Now, I personally think the “direct” in direct object reference comes from you only being able to reference one object at a time, meaning “direct,” compared to a list object at the same time, but I couldn’t find any resources to support or deny that.
Again, What is Insecure Direct Object Reference?
Now you know what a direct object reference and broken access control is, I can explain what an IDOR is. An IDOR is when you insecurely reference an object, hence the name. Say to edit your profile on socialwebsite.com, the URL is socialwebsite.com/users/16/edit. You notice your profile ID is 16. You wonder what would happen if you change the ID to 15. You do that and you now have access to edit user 15’s profile. That’s an example of IDOR, and that’s why its apart of the broken access control vulnerabilities on the OWASP Top 10 list.
What Are the Impacts Of IDORs?
There’s lot of different impacts of IDORs as there are different areas within a website that uses IDs. If you don’t know what an impact means in bug bounties, an impact is what an attacker can do with this bug and how it affects the company. A few IDORs that I’ve came across enabled me to delete a user’s post by switching my post’s ID to someone else’s post’s ID, stealing someone else’s account (account takeover, aka ATO) by changing my ID in the URL of a password reset endpoint to someone else’s user ID, etc.
Generally, the impact of IDOR falls into modifying, deleting, or viewing data that an attacker isn’t supposed to have access to.
How to Prevent IDORs?
IDORs happen because of two reason:
- Weak or no access control mechanisms in place
- Non-obscure IDs
When there’s no access control mechanisms in place, you can easily switch out your ID for someone else’s ID in a function and it will work.
When there’s weak access control mechanisms in place, you probably won’t be able to simply switch the ID, but you will try to bypass their prevention by maybe changing the HTTP Request Header, for example.
When the ID being used is easily readable and predictable, such as the ID of 12, then that’s a non-obscure ID that someone could probably guess another valid ID is 11.
To prevent theses, a server should preform some type of verification that you as the user should only be referencing your own ID when using sensitive functionalities like editing your profile, changing your email, or changing your password. The web application should also use unpredictable IDs like a hashed ID. “Hashing is the process of transforming any given key or a string of characters into another value.”
How to Bypass IDOR Prevention?
If an application is using any type of encoding/hashing of the ID, you can try decoding it back into it’s number, change the number, then encode/hash it again. Sometimes you can even replace the obfuscated ID with a plain number and it’d work. Also switching the file type or the request header may be a bypass.
IDOR Methodology
When hunting for IDORs, you should start with creating two accounts. The reason is that if you do find an IDOR, you aren’t tampering with another user’s data.
The next thing to do is look for functionalities that uses any type of IDs to view, edit, or delete data. While you look for functionalities, you should have BurpSuite or ZAP running to collect the HTTP traffic. That’s so you can send a request to a repeater to test for IDORs when you do spot an ID. And if you do switch the IDs and it doesn’t work on first try, that’s when you start using bypass methods.
How to increase impact of IDORs?
As it seems to me, the higher the impact, the more you are paid. You can increase the impact of any bug by chaining it with another bug. Bug chaining is when you use two bugs to perform a higher impacting action. Say you found an IDOR to change a user’s profile description. How can you create a greater impact? You can try to execute JavaScript on their description (called Cross-Site Scripting, or XSS for short). To find higher impacting IDORs without bug chaining, you can try to find IDORs on sensitive functionality that may lead to ATO, information leaks, etc.
Can IDOR Hunting Be Automated?
Hunting for IDORs can be automated with a tool called Autorize. “Autorize is an automatic authorization enforcement detection extension for Burp Suite. It was written in Python by Barak Tawily, an application security expert. Autorize was designed to help security testers by performing automatic authorization tests. With the last release now Autorize also perform automatic authentication tests.”
Thank you for reading. Hopefully you now have a basic understanding of IDORs and have a desire to extend your knowledge about it on your own. :)
