Hunting Insecure Direct Object References (IDORs)

This blog post was written by Rodney Kariuki.

Introduction

Insecure Direct Object Reference (IDOR) is a type of access control vulnerability that arises when the references to data objects (like a file or a database entry) are predictable, and the application uses user-supplied input to access objects directly without performing other security checks. Therefore, an IDOR is essentially missing access control.

How IDORs Work

Web/mobile applications’ session management is very important for end users. Session management consists of two important parts, authentication and authorization. The authentication part is the answer of the “WHO AM I?” question and the authorization part is the answer of the “WHAT CAN I DO?” question.

In the image below we have a user whose ID is 1234. They should be able to view their account information only. However, when the user manipulates the Id and changes it to 1235, they also receive details of that other account. Woah. What just happened?

An IDOR vulnerability has just been exploited since there is no identity check in place before the server returns the private info of users. The server was not verifying that the user was in fact, user 1235 (no authentication) or if they were an imposter. It simply returned the information asked.

In the above example, we were able to manipulate the URL in order to exploit an IDOR.

NB: IDOR vulnerabilities can also be found in numerous other places i.e., APIs, CRUD functionality, and in complex permission hierarchies.

Another Example

IDORs are not just limited to reading other users’ information either. It can also be used to edit data on another user’s behalf.

Imagine this: a user can change their own password on banksite.com by going to:

https://banksite.com/change_password?Id=1234

What if they manipulate the Id to 1235

https://banksite.com/change_password?Id=1235

Without any identity checks in place, they can essentially change the password of another user (without their consent) and take over their account (provided they also know the other user’s email or login username).

In the above example, horizontal privilege escalation has just occurred.

How to find IDORs in Bug Bounties

1. Find endpoints with IDs in the request.
2. Change the ID (to another account you own).
3. If it works, it’s an IDOR.

OR

1. Find endpoints that require admin permissions.
2. Log in to another account that has guest permissions.
3. Repeat the requests to the admin endpoints, changing the cookies.
4. If it works, it’s an IDOR.

Implications of IDOR Vulnerabilities

An IDOR, even low-impact IDORS, can cause significant impact. Especially when chained with other vulnerabilities. Some of the implications include but are not limited to:

• viewing confidential information.
• horizontal privilege escalation.
• vertical privilege escalation.
• modifying/deleting other users’ information.
• posting information under other users’ names, etc.

IDORS in the Wild

1. [IDOR] Deleting other people’s tasks: Reported to: Open-Xchange; Bounty: $300.
2. IDOR bug to See hidden slow-vote of any user even when you don’t have access right: Reported to: Phabricator; Bounty: $300.
3. Validation message in Bounty award endpoint can be used to determine program balances: Reported to: Hackerone Bounty: $1500

What Makes them Great First Bugs?

• No technical knowledge required to find them.
• Can be easy to find (but requires patience).
• Can be found manually, or by using automation tools (autorize).
• Security impact easy to describe (users performing actions they should not be able to).
• If you see an ID, change it to another ID.
• If you can do something with a high privileged user, try it with a lower privileged user.

For an IDOR vulnerability to be exploitable, there must be a direct object reference to a data object, and a lack of access control. So to prevent IDORs, we can either:

Avoid direct object references.

Implement detailed access control for each application resource.

Let’s discuss them both

Avoiding Direct Object References

We can use an unpredictable hash or random string to refer to objects instead of using a simple, predictable, and incrementing numerical ID. This makes it more difficult or even impossible to enumerate real data IDs and harvest sensitive data.

For example, instead of having:

https://banksite.com/change_password?Id=1234

We can have:

https://banksite.com/change_password?Id=miTNakL3dRSyAD7tH

NB: However, this shouldn’t be relied upon as a full solution since the random strings or hashes could be reverse-engineered or enumerated elsewhere from the application. This method just makes exploiting IDORS harder, not impossible.
We can also use an Indirect-Reference map. It replaces the actual references (such as user IDs, names, keys, etc.) with alternate IDs that map to the original values. The mapping between the alternate IDs and actual references is maintained safely on the servers.

For example, instead of having:

https://banksite.com/account?Id=1234

We can have:

https://banksite.com/a/c

Then, refer to the indirect reference map to look for the actual reference. This way, direct references containing users’ financial information will not be exposed.

Validate User Access

The root cause of IDOR vulnerabilities is missing access control.

If we 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 we 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.

For example, some websites prompt you for your password again if you want to change your password or proceed to checkout.

Useful Tools in Looking for IDORs

• A web proxy e.g., OWASP Zap, Burp Proxy
• Firefox Containers – Opens the same tab in its own isolated container. This enables us to login to the same site with 2 different accounts in the same window. Saves time and effort from having to use 2 browsers or switching back and forth to an incognito window.
• CyberChef – used to decode IDs that aren’t in the numerical form e.g., Base64, or decode the value of cookies.
• Autorize – A burp extension that automates finding authorization vulnerabilities. We can give the extension the cookies of a low-privileged user and navigate the website with a high privileged user. The extension automatically repeats every request with the session of the low-privileged user and detects authorization vulnerabilities. It is also possible to repeat every request without any cookies in order to detect authentication vulnerabilities in addiction to authorization ones.

Conclusion

IDORs are a dangerous vulnerability that can threaten users’ privacy and the integrity of an application. Therefore, it’s important to find out if they exist in an application and remediate them.

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 IDORs. 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.

That’s it for today’s security lesson. Thanks for reading!

References

OWASP Juice Shop: https://github.com/bkimminich/juice-shop

OWASP Web Goat: https://owasp.org/www-project-webgoat

Portswigger Web Securit Academy (IDOR): https://portswigger.net/web-security/access-control/idor

Intro to IDORs: https://vickieli.dev/info%20leak/intro-to-idor

IDOR Tutorial Hands-On: https://thehackerish.com/idor-tutorial-hands-on-owasp-top-10-training

Disclaimer

The MacroSec blogs are solely for informational and educational purposes. Any actions and or activities related to the material contained within this website are solely your responsibility. The misuse of the information on this website can result in criminal charges brought against the persons in question. The authors and MacroSec will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.