What is an IDOR attack?

An insecure direct object reference (IDOR) is a type of vulnerability that occurs when a threat actor is able to gain access to unauthorized objects by manipulating identifiers within areas such as the URL parameters. This means that there can be certain aspects of a site that an attacker could manipulate to gain information or control over certain parts of the site. An example of this is the URL parameter, which is a portion of the URL that appears after the question mark where there is a key and a value that is separated by an equals sign, like (ex. ?id=20, where the key is the value id and the value for the key is 20).

IDOR vulnerabilities are caused by improper access controls in the web application. Access controls are basically a type of security technique that regulates what types of resources a user can access within an environment. So, if a web application has improper access controls in place, then an attacker could possibly manipulate the site to access unauthorized information. An IDOR vulnerability can allow an attacker to access another user’s account information by manipulating the value parameter of the URL.

 Performing an IDOR attack

To perform an IDOR attack, you typically need access to an account within the web application. The picture below shows the account that will be used for the IDOR attack. This is a simple customer account with no other access to any account.

Once you have created an account on the website, use Burp to scroll through the different directories to see if any of the pages contain a possible URL parameter to target. Once we have looked through all the directories, we will go to the proxy and HTTP history to check all the directories that were found on this site. On the customers/account page of the website, it shows below that the page contains the URL string /api/v1/customer?id=15. This URL string contains the parameter ?id=15, which could be manipulated into giving information about other accounts if there is no security check in place to prevent it.

Now that we have found a potential target URL parameter to manipulate, we can test if this site is vulnerable to an IDOR attack. We are going to use Burp Repeater for this which allows us to modify the request that we have captured and send the modified request to our target. We will send the request with the specific URL string from HTTP history to Repeater. Once the request is in the Repeater tab, you can send the request with your id and session cookie and see the username, email, and id of your account.

However, once a different ID number is inserted within the id parameter and sent even with the same session cookie as the original account, we’re able to gain the username and email of a completely different user. Even though we had the globally unique identifier (GUID) of the original account, we can still access the information of another account if we change the URL parameter. A GUID is basically an identifier unique to the request that you are sending, which validates that we are sending a legitimate request, so the site should only respond with information pertaining to us.

So in this case, we have a session cookie that is our GUID, and it is unique to the request that we are sending. However, even though this should signal to the web application that we are only authorized to obtain information pertaining to us, we can still access other account’s information if we change the ID parameter. This proves that the web application does not check if the user is authorized to access the information that they are requesting.

This is bad because we have access to the usernames and emails of different users on this site. Now that we have the username and email, we could check if there had been previous accounts that had the same username or email that had their password breached and attempt a credential stuffing attack using their past password. We could also do a normal brute force attack if the web application does not have good security controls to prevent these types of attacks. Lastly, an attacker could also use the email that they were able to obtain to perform a phishing attack, where they would send an email posing as the web application IT services to gain sensitive information like passwords or even credit card numbers.

Performing a brute force attack

Now that we know that an IDOR attack is possible on this web application, we can now perform a simple brute force attack using Burp Suite to see which parameters can be used to access the account information of other pages. We will send the URL that we found in the HTTP history to Intruder and use the sniper attack type because we will use only one payload in a single place. Here, we will attack the value of the parameter. We will set a payload of numbers; for this example, we will target numbers from 1 to 20.

Now, we can see which ID parameters are valid to enumerate information about other accounts. Within the brute force attack, we can see that there are many different parameters that we can use to access different people’s information.

Mitigation Techniques

  • Make sure there are proper access control checks for all the objects that users should be able to access. Configure the authorization controls so that the users will not be able to obtain access to information that they should not have access to.
  • Avoid exposing the parameters of the URL that an attacker can manipulate and use for an IDOR attack. Sensitive values should never be transmitted via GET parameters.