A Guide to IDOR
In this article you’ll find the answers to the following questions:
What is an IDOR?
What are its origins?
How to find and exploit IDORs and what are the impacts?
How to prevent and mitigate IDORs?
Introduction to IDOR
So, first things first: Insecure Direct Object Reference, referenced from here on as IDOR, is a type of access control vulnerability, in which an user can access objects of the application by manipulating a parameter or input he controls. IDOR usually is associated with horizontal movement though they can also appear in vertical privilege escalation scenarios. The most emblematic case of IDOR is the numeric ID parameter, a common feature in web applications that is used for various things such as accessing profile data or the entries of a database.
Origins
As to why it happens, there are two factors that combined make up for an IDOR, first is the lack of a verification that checks whether the user can access whatever they are trying to access, be it a check on the privileges of the user or if he should be allowed to access that data. Secondly, is a predictable pattern that a malicious user can alter to trigger said vulnerability. Below we can see a snippet of a code vulnerable to IDOR to give an idea of what logically is goin’ on behind the application.
How to Find and Exploit IDORs
Like most vulnerabilities, understanding the flow of the application and paying attention to what you can control in these interactions is the way to come up with impactful attacks. In the below portswigger lab we can see a case with a live chat and a feature to view transcripts, these transcripts are requested by a GET request with a predictable numeric endpoint.
In the image above you can see the request for the transcript, the numeric endpoint suggests that there might be others files to request.
Trying 3.txt gives us a valuable information, the message suggest that in case there is a transcript, we might be able to access it. The next image shows us the vulnerable file, a transcript that has the password of a user and allow us to take their account.
In this example we have an application that separates users conversations trough a predictable set of endpoints, notice how in the code snippet showed earlier there was no access control mechanisms that prevents users to access other objects or, in this case, transcripts. This give us an idea of the flawed logic that is behind IDOR vulnerabilities, by simply altering that numeric value we can enumerate the transcript from other users, acessing other users information and data is the most common impact of IDOR, others implications are performing unauthorized actions on behalf of other users and manipulating or destroying data from the application.
Although the example shows a numeric endpoint in clear text, parameters can be also encoded, you might still be able to decode it, change it’s values and resend it to the application to test it’s behaviour. In more general terms, you should analyse every request in the application and it’s features paying close attention to how information and files are requested, if it uses controllable parameters to access any type of data and the parameters are predictable you should try messing with those values to check the application’s behaviour, this include POST requests with data in it’s body as well as whatever input that fall under the mentioned circumstances.
How to Prevent and Mitigate IDOR
There are a few ways to address the issue, some of them tackle on the main problem which is a access control issue and some others only make it difficult to exploit, like when you have a controllable parameter, but the pattern is so unpredictable it just makes the exploitation unlikely.
Now let’s look at some of the ways you mitigate this vulnerability: one of the solutions is to create a mapping to the objects and create indirect references to them, this essentially means creating temporary reference maps filled with random keys that calls objects for the user, these maps are then internally mapped to the actual objects and should be generated per session each. Another possible solution is to use a salted hash to replace the direct identifier, the hash should be salted at application level so even if the attacker can deduce the hashing algorithm it won’t be able to reproduce them due to the salting, more information on how to implement this particular solution can be found at reference 2 of this article. Although the previous methods are efficient at preventing IDOR, neither of them address the access control issue directly, the solution that does so is to create mechanisms to accurately handle session management and that checks the users access permissions on the objects in question, so even if an attacker can find the value of a object he still won’t be able to reach it’s data.
Final Thoughts
In this article you’ve learned about a common web application that is under the Access Control topic, number one vulnerability in OWASP Top 10 of 2021, hopefully you’ve learned how to identify and exploit IDORs by now. I strongly encourage the reader to not stop here and check the references of this article, read about the OWASP Top Ten, practice in PortSwigger’s labs and help put forth the Keep Hacking mentality.
References:
