Very early on in my cybersecurity career, while I was still shadowing a colleague, I spotted the number "462050" in an HTTP request packet in Burp Suite. The packet was requesting the user's profile page. This number was part of a JSON at the bottom of the request, and was next to the "userID" key. So, I wondered, what happens if I increment this number by 1?

IDOR (Insecure Direct Object Reference) is an access control vulnerability where user-controlled input can be used to access specific files or resources. Take, for example, a banking website from which you can download your current account information. This is stored at https://bank.com/spreadsheets/12345678.xlsx where 12345678 is your account number with the bank. This file should be locked be only accessible by you, but what if the user with the account number 87654321 edits the URL in their browser from https://bank.com/spreadsheets/87654321.xlsx to https://bank.com/spreadsheets/12345678.xlsx? Hopefully it will give them an error and say that they are not authorised to access this page. If the account spreadsheet of the user with the account number 12345678 is returned, however, that's an IDOR vulnerability.

The "Object" here is the account details spreadsheet, the "Direct Reference" is the calling of .xlsx in the URL, and the "Insecure" is the fact that it is not locked down so that only the relevant user can access it. During the engagement mentioned in the preamble, changing the userID value to another relevant userID would return that customer's personal details.

So how do we fix this problem?

In the real-world example provided, there are two parts to the remediation. Each goes some way to prevent it on their own, but together form a more complete solution.

1. Changing the "userId" fields to be more complex, non-incremented strings would prevent the guessing or automation of access to other users' data.

2. Using the Authorisation header as a check against the user's access privileges would prevent access to other users' data as the header contains the current user's session data.

While "security through obscurity" (i.e. step 1 above) is not enough on its own, as mentioned it makes it much harder to run an automated step-through attack to see what can be accessed. For example, if the userID number mentioned at the start, 462050, was instead a multi-character type string such as "8smhFH-Fh42oa-6L2meT" it would be much more difficult for an attacker to guess what another userID might be. Add into this an authorisation mechanism being in place that limits access to account-specific resources based on the Auth ID and IDOR vulnerabilities will be a thing of the past.

The PortSwigger labs contain a great example of an IDOR vulnerability, where logging in with one user and then changing a parameter allows access to any other user's profile.

Here we have logged in legitimately to a user account, but you can see in the address bar that there is a parameter for which account we are logged into. Changing this parameter to “Carlos” allows us access to that account.

In both of these instances, we can see that the session cookie being passed is the same, but access is still granted. This means that the parameter is not being checked against the session cookie to see whether or not the user should be granted access to the account.