Insecure Direct Object Reference – Prevention and Detection of IDOR

When the application is allowing the user-supplied input to access resources directly without proper authentication and authorization check then Insecure Direct Object Reference (IDOR) occur. So, this can lead to serious issues. Consider the below URL for a simple example.

https://www.example.com/accountInfo/accId=1

This URL is showing the account information for account id 1 user. Now, the value 1 is the identifier in this application that fetches data associated with the users. If an insider wants to take this as an advantage to view the account information of other users. Simply attackers could pass the values from 2 till n number.

 https://www.example.com/accountInfo/accId=2  (attacker modifying the account id to 2)

Modifying the parameter in the URL will bring the information of account id 2 users. In this way information of other users is stolen without any harm to the application or without sweating.

Not only in url even if the parameters are sent in POST request, it can be modified intercepting with proxy tools.

POST /accountInfo HTTP/1.1

Host: example.com

Content-Type: text/plain

Content-Length: 11

accId=1 (attacker can modify the account id to 2)

The same attack with getting requests can be done with POST with the above example. Even, static files in the webserver can be accessed using the vulnerability. Some application feature works like user chat details stored in static files in the filename as incrementing. It can be viewed by the user anytime. Now, attackers can use this function to read the chats of other users and gain private information.

Preventive Measures

Let us look some use ways to prevent this attack.

• Enforce Strong Access Control over resources. Like resources mapped to the owner with some sort of random non-guessable number or non-sequence keys.
• Check the user authorization before issuing the resource when the user requests it. A strong User role function should be implemented in the application. Validate the user role and user hash with the resource before the resource is released.
• Don’t map the object with a direct id instead use of hash is handy in this case. To make more difficult use of salt along with hash is good. Refer the OWASP IDOR prevention cheat sheet which has a code snippet for hash

Detection In Logs

• Same Ip addresses accessing the different parts of accounts, I.E accId=1 (attacker can modify the account id to 2) , continuously changes in id numbers from the same IP addresses within a specific timeline, that indicates the Insecure Direct Object is accessed.
• Source IP address has successful HTTP status codes such as 200, Failure codes like 4xx, or any other indicates the attempts were made and not successfully exploited the code.
• Simple Correlation rule Logic : SAME Source Ip addresss : x.x.x.x AND WAF/RASP Logs ~ contains accId=1 to 1000 AND Status Codes ~ 200
• Check for web application logs , WAF and RASP for for insights on what is exactly accessed from an external party.
• Review the vulnerability scanners results and check whether the applciation has any new vulnerability for IDOR in past scan results.