Insecure Direct object Reference

IDOR Vulnerability

Hi Folks!

This is my 12th blog on Web Application Security Penetration Testing. In this blog I will explain “What is IDOR?” “How to test it?” and “How to exploit this vulnerability?” along with it’s Impact and remediation.

In my last blog I have explained how to perform CSRF attack to takeover user’s account. If you haven’t read it yet please navigate to below link.

Account Takeover [Via Cross Site Request Forgery]

What is IDOR?

Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. There can be many variables in the application such as “id”, “pid”, “uid”. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This is called as Insecure Direct Object Reference.

For Example:

1. Accessing Customer Information Directly from database using Customer_Number. Here, Attacker can access any database customer object directly using Customer Number.

2. Accessing Static Files Using Static numbers.

3. Accessing Profile Information of the user using Id.

Best target to test:

Edit, Delete, Create, Update, Reset Password, service endpoints, API endpoints, etc. like

User-ID, Profile-ID, Client-ID, Report-ID, APP-ID, Reset-ID, Delete-ID, Customer-ID anything like this.

Let’s exploit it on live domain for better understanding. Please note that I am masking the actual host to maintain confidentiality So let’s consider our target domain is redacted.com as usual.

I was navigating through application where I have found below endpoint.

https://redacted.com/api/api-security-broker/v1/users/187

Where 187 seems to be User-ID. After visiting this endpoint in Burp Suite proxy tool I have got below response.

Object data exposed for USER-ID 187

Let’s take this object-specific request into the intruder to launch automated attack. Set the attack vector as User-ID as shown in below screenshot.

Request Captured into intruder to Launch Automated Attack

Set the Positions of the payload. Here, I am changing User-ID from 1–500 to check whether I will have access to other user details by changing their User-ID’s.

Set Payload Positions for Attack

Click on Start button from right upper corner to launch the attack. I have received below responses which is sorted based on response length.

Profile ID Enumerated Using Intruder Attack

I have exported this data into excel sheet. Notice I was able to access more than 48+ User’s data by just changing their Profile ID. Data is masked due to confidentiality.

Data Received by Exploiting IDOR

Data Received by Exploiting IDOR

Impact:

Direct Access to other users objects, so that you can View, Edit, Delete, or modify information of other objects directly. It has huge impact on application users.

Mitigation:

Use per user session which prevents attackers from directly targeting unauthorized resources. If attacker try to do so, session will be invalid for attacker.

Use proper access control check while serving resources.

Use indirect reference mapping where we can convert actual values to the application like Id, Uid, keys, Name into cryptographic values which is random in nature and will be mapped with actual values on the server. In this way attacker cannot judge the actual values to the other user.

References:

https://hackerone.com/reports/265284 https://hackerone.com/reports/52176

https://hackerone.com/reports/42587

https://codeburst.io/hunting-insecure-direct-object-reference-vulnerabilities-for-fun-and-profit-part-1-f338c6a52782

https://hackerone.com/reports/52646

HackerOne disclosed on HackerOne: Insecure Direct Object Reference...

Please do like and follow for more reads.

Thanks!