Introduction
In this article i will be going over Broken Access Control(BAC) which also includes IDOR. Some might see this as a separate issue type but in reality IDORs are simply another form of BAC.
BAC is a beautiful issue type and i think it’s often overlooked in bug bounties but you have to pick the right target of course! You target needs at least:
- To create accounts or give you accounts
- Different privilege levels
- Direct object references for IDORs (example userID=123)
Let’s start with IDORs
Insecure Direct Object Reference (IDOR)
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.
Attack strategy
We can basically take a manual or semi-automated strategy for this.
