IDOR means Insecure Direct Object Reference. It’s one of the easier web application vulnerabilities to understand (or at least, the basic concept is). An IDOR happens when a user of a web site can find ways to access pages and data that belong to a different user on the same site, by changing a parameter in their browser’s address bar or in other resources.
In other words, an IDOR is likely to happen when the web applications does not properly check if the current user has permission to access the requested page, image or file.
How does it work?
Imagine you are signed up to a web site. Clicking on a link to display your profile information takes you to a page with a URL that looks like this:
https://targetsite.com/userinfo?id=7691
If changing the value of the id parameter to something like 7600 and reloading the page displays the profile information of a different user, then you’ve found an IDOR. On a properly configured web app, there should be a check to verify that the page requested does indeed belong to the logged-in user (you, in the present case).
IDORs allow a malicious user to impersonate other users. If one of these other users happens to have admin privileges, then an IDOR can lead to a web site takeover.
Where do you find IDORs?
There are three main areas where you should look for IDORs:
In a query component:
This is when you can change the value of a URL parameter (in your browser’s address bar) that is passed to the page requested by a given user, as seen in the example above. That’s the simplest scenario.
In POST variables:
This is when the parameter to look for isn’t located in the URL but is passed to the HTML code of the page. In particular, if you examine forms on a web page, you may sometimes find hidden fields used to pass a user identification parameter through a variable.
Use your browser’s developer tools to examine the page’s code and, in a form section, look for lines like these:
<input type="hidden" name="userinfo" value="7691">
Then change the value, reload the page and see what happens. If you can access a different user’s data, you’ve found an IDOR.
In cookies:
Web sites use cookies to allow a user to stay identified during an entire browsing session. By using cookie headers, the browser gives the web site the info it needs to track the user without requiring them to log in to every page they visit.
The header of the web request could look something like this:
GET /userinfo HTTP/1.1
Host: targetsite
Cookie: user_id=7691
User-Agent: Mozilla/5.0 (Ubuntu;Linux) Firefox/94.0
You can use Burp Suite to modify the value of the user_id parameter in the request and see if this leads you to a different user’s data. If so, you’ve found an IDOR. You can also use your browser’s developer tools to modify cookie values.
Do keep in mind however that a session id will usually be an encoded string of characters that you can’t just increment as you want. So decoding the string will need some extra work. But some inexperienced web developers may feel confident storing the unencrypted user id in the cookie, in which case you may have an easy way in.
What next?
If you want to take things further, InsiderPhD has a tutorial video that’s worth checking out, giving practical examples of how to spot and exploit IDORs.
And this in an Intigriti video walkthrough of a very simple example of identifying and exploiting an IDOR.
Also, TryHackMe has a room dedicated to IDOR, as well as an IDOR task in the Advent Of Cyber 2021 (go to task 6).
