Insecure Direct Object Reference (IDOR)

Today I want to talk about one of my favourite vulnerabilities right up to where my knowledge gap begins, like you I am still learning and writing about the things I am learning about is my way of retaining the knowledge. Before jumping straight into a highly paid vulnerability, a quick word on authorization and authentication.

Authentication lets the application know who is using an app, while authorization means the level of features you have and the level of actions you can perform.

IDOR occurs when an application refers to some other internal objects via different parameters in an insecure manner. - Abartan Dhakal

While browsing the web you may have seen lots of parameters like 'uid','id','pid' and many more with some sort of numeric (like id=6672,user=90087). Nowadays to make it harder for attackers to enumerate the userid and exploit it, there is a wide use of GUID/UUID (something like  3acde797-f7c3-4a74-a1cb-729fe4117a04) in those parameters. We will talk about it later.

So whenever you try to modify that userID from one that is yours to that of others and if the data gets changed on the other user's end, then that's IDOR.

How do we find it?

Run Burpsuite's proxy and start surfing around the webapp. Let the burpsuite's spider fuzz the possible directories and parameters. At the same time, go through the each web pages and always check the parameters which has numbers or username in it. When you find it you are ready to goto next step.

How do we exploit it?

When you find the parameters which have some kind of reference to the internal objects, then you can start play around it. Whenever you see a cookie value from the header or parameter with username in it, try to change that to  other username and see the behaviour. Similarly, check the parameters which has userid, usernumbers and so on then try to modify those numbers and check if you can gain access to other user's data or modify other's data. It is always recommended to create two user accounts and test for it as you will know whether the data is being modified/accessed even if the web app shows error or success message.

If you become able to access/modify other user's data, then congratulations brave hacker, you just found an authentic IDOR that is ready to exploit.

But what if there is a GUID?

A GUID can foil your plans and make it really hard to exploit this hypothetical IDOR scenario. So when you come across one try to create a few users in order to get their GUID so you can try to understand how the GUID is formed. If there is no specific pattern then only thing to do is to enumerate the GUID. Sometimes there faults in the API that can leak the GUID, sometimes CORS misconfiguration can like it too, so you need to try and find a way to enumerate the GUID and perform IDOR.

IDOR sounds dangerous, how can I prevent it ?

Before you start super patching the area, map all the areas where the application makes direct reference to an internal object. Afterwards make a strict access control rules, validate all the user input and make sure it is validated both client and server side and at the end, you can implement GUID to reference it to an internal object.

Hopefully I could help you work out the key concepts around IDOR and how to prevent it. My article may be lacking in knowledge, but right now its all the knowledge I have, when I have more I will update the article!

If something could be added or if there is anything mistake, feel free to reach out to me on Twitter @imhaxormad. You can also hire me as a freelance writer if you would like something similar written, check out my post on Secjuice Jobs.

Happy Hacking!