This blog was written by an independent guest blogger.

This article explores how you can locate Insecure direct object references (IDORs) using Burp Suite. Primarily, there are two ways to test the IDOR flaw, manual and semi-automated. For automation, this article focuses on the Autorize Plugin in Burp Suite.

What are Insecure Direct Object References (IDOR)

Silent Breach discovered an IDOR vulnerability on the US Department of Defense website in November 2020 and discreetly notified it to the DOD’s Vulnerability Disclosure Program. The flaw was solved by including a user session method into the account setup that required initially logging in to the website.

That was one of the IDORs incidents, but what is an Insecure Direct Object Reference?

“Insecure Direct Object References (IDOR) occurs when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.” – owasp.org

Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter that points to an object directly.

Access control challenges are the source of this vulnerability. The word IDOR became famous once it came into the OWASP’s top ten. However, it’s really just some other form of Broken Access Control.

IDORs can cause privilege escalation either horizontally or vertically. To be considered an IDOR, they must meet the preceding requirements:

The request contains an entity identification, whether as a GET or POST option.
There must be an Access Control flaw allowing the individual access to information, for which they shouldn’t be allowed.

Examples:

GET /receipt.php?id=18
POST /privateInfo.php

{userId:03,name:”bob”}

GET /invoice/test.txt

We have POST and a GET request with an identifier. In most cases, user A can only see receipts or private details that belong to him. An attacker can get an IDOR if he modifies this identifier and receives the same information as user A.

It might appear to be a simplistic explanation of IDORs, but that is essentially how they function. The interesting part is how we could automate scanning for this. We may use either a manual or semi-automated technique.

If you are just getting started in bug hunting, I suggest manual testing initially. It’s common practice to learn and grasp the working knowledge of your tool before putting your hands on it. You genuinely get to go into the depths of your capabilities.

Semi-automated test for IDORs

To automate the testing of IDORs, we need Autorize Plugin in Burp Suite.

You can install the Autorize plugin in the Burp suite from the Extender tab -> BApp Store.

After installing the autorize plugin:

Navigate to your target webpage, log in to User A (test2/test), and capture the traffic.
Copy the request (cookie and header details) and paste it on the Autorize tab.

Turn on Autorize.
Go to the target webpage, login with User B (test3/test), and capture the traffic.
Burp then makes the identical request with the given cookies and color-codes the outcomes for us.

Lastly, explore the target Web App and test every feature that requires admin credentials and is not accessible via a regular user; if you receive a Bypass/Enforced response, you have an IDOR vulnerability.

Testing IDORs manually in Burp Suite

To test the IDOR manually, I am using the Port Swigger lab here. Fire up Burp Suite and access the Portswigger Lab.

It’s good practice to set the target scope in Burp Suite. As in our case, you can add the lab URL as the target scope, or you can add only the domain name.

I usually tick the advanced scope control, as it provides us with regex options if necessary.

After setting the target scope, explore the target webshop. Browsing through the webshop reveals a variety of features. By this time, the site map must have clogged up with all the various requests.

We can see various responses, but the one we’re interested in is the download-transcript.

Navigate the webshop, capture the traffic on the proxy tab and send it to the repeater tab.

When we modify this download transcript number, the server will no longer verify that we have permission to download it.

We must be capable of login into username Carlos and the password we just got. We don’t particularly need to be signed in to get the documents because this is an unauthenticated IDOR.

Conclusion

The two ways we can use to test IDORs are:

Manual testing using Burp Suite.
Semi-automated testing using Autorize Plugin from Burp Suite.

Implementing an access control system is the only genuine approach to address this vulnerability. The server must authenticate the user before it can fulfil the request.

Read More