Member-only story
What is it
IDOR: Insecure Direct Object Reference
These types of vulnerabilities arise from acces control issues. We will devote another entire chapter to those types of vulnerabilities. The term IDOR was made popular in by appearing in the OWASP top 10 but in reality it’s simply another type of Broken Access Control issue. IDORs can manifest in both horizontal and vertical privilege escalation. To speak of an IDOR, the following conditions have to be met:
- An object identifier exists in the request, either as GET or POST parameter
- A Broken Access Control issue has to exist allowing the user access to data they should not be able to access
These terms may seem abstract so let’s look at an example:
- GET /invoice.php?id=12
- POST /personalInfo.php
{personId:23,name:”tester”}
- GET /invoices/1234.txt
In these examples we can see a POST and a GET request being made, both contain an identifier. In a normal situation, the user can only access invoices or personal data that belong to them. If we however change this identifier and get data returned that does not belong to our user, we have an IDOR.
This may seem like a simple interpretation of IDORs, but this is basically how it works. The complexity comes from how we can automate looking for this and from the different users in involved.
How do you look for IDOR vulnerabilities?
We can basically take a manual or semi-automated strategy for this.
Manually
Manually searching for IDORs is probably the easiest way. In a previous chapter we went over your main attack strategy. This stated that you should explore the website with your MitM proxy in the background. (See general attack strategy). Burp suite has an option to show parameterised requests:
