Explaining vulnerabilities : IDORs {Bug bounties}

IDOR (insecure direct object reference) is a broken access control vulnerabilityThe main difference between an classic IDOR vulnerability and a simple BAC vulnerability is that to have an IDOR , we need to have the following conditions met :

-> an object identifier exists in the reques (GET or POST)

-> there needs to be an access control issue that allows a user to access an object that they should not be able to

Let’s take a look at some request examples :

GET /accountInformation.php?id=3

POST /updateUsername.php {accountID:1, username:”administrator”}

In the examples, we have a GET and a POST request, that both contain identifiers. In a safe environment, the user can only access the account information or update the username of their own accounts. If, however, we change this identifier and receive some data that doesn’t belong to us, there is an IDOR vulnerability in place.

As with any other vulnerability, we mainly have 2 ways of hunting for them. A manual, and automated/semi-automated way.

Manual way

Manually hunting for IDOR vulnerabilities, is probably the easiest way to do.In a previous episode of this bug bounty series, I covered a main application methodology. There, I also covered the exploration of the application , and suggested that you should have a proxy running in the background (mostly burp). That is because, burp has an option that shows only requests with parameters.We will go through these requests manually and only send the requests that contain identifiers to the burp ‘Repeater’.Sometimes, we will need to replace the authentication methods that are expected by the server with valid authentication tokens . JWT and session cookies might need to be replaced.You will need to identify which authentication mechanism is being used and make sure you replace any expired authentication methods with valid ones. Get new valid tokens by logging in and making similar requests.

Caution : You are highly recommended to create two different accounts when testing for these kinds of vulnerabilities, in order to not leak sensitive information from the organization, which may result in legal problems.

Example of IDOR identification & exploitation:

We identify a request that contains an identifier:

GET /bill.php?id=2

We send it to repeater. Then , we identify that the request contains a JWT token in the authorization header that is expired. (you know this, because when you will launch the request, it will return a 500 response)

Check the HTTP history in burp and grab the latest JWT token. (or , log in the application and afterwards check the http history in burp)

Replace the expired JWT token. (if all goes well, it should return a 200 OK response.)

Now, create a new account on the application.

Log into that account and check the HTTP history in the proxy tab in Burp & grab the latest JWT token.

Last step, is to replace the new JWT token in repeater. If you receieve a 200 OK response and you can see the bill of the previous account, you have an IDOR.

Semi-Automated way

Here, you can use one of Burp Suite’s tools, “Burp Authorize” and also the match and replace tool.

While semi-automatically hunting for IDORs is possible, I still highly recommend manually hunting, since even if you don’t find an IDOR, you might find something else that is interesting and would require further testing.

Thank you for your attention and I hope you’ve found this useful. Peace!