IDOR vulnerability (Insecure Direct Object References)

An overview of IDOR vulnerability

It takes place when authorized user input is used by any other unauthorized entity to gain access to a specific application/resource/software/operation. If not tackled promptly, a well-planned IDOR attack leads to serious dangers.

At times, Insecure Direct Object Reference (IDOR) is not a direct threat. But, using this type of access control attack, skilled hackers/threat actors can create a threat-conducive environment for a bigger and damage-causing attack.

‍

IDOR and OWASP Top 10

OWASP Top 10 is an expert-created list of security vulnerabilities occurring at the highest intensity and causing the most notorious damage. The list is based on the inputs of security experts in various communities and is updated generally after 3-4 years. IDOR showed up in the 2017 list. 

The term is used to explain cyberattacks where the threat actor directly attacks the reference objects in order to gain unverified access to a restricted resource or application. 

OWASP IDOR definition reveal that the vulnerable websites or applications tend to display a direct reference to the internally implemented object like user ID. Due to this, the actual reference/identifier or its format is disclosed. Using it, the unsolicited user is allowed to access the web application-owned resources/operations.

‍

IDOR Types

• Body Manipulation where the threat actor alters the default or trusted-user defined values of aspects like checkbox, form fields, and radio button. By doing so, they are allowed to use the authorized users’ access data for their usage. 
• ‍URL Tampering is a type of IDOR attack and involves manipulating client-side URLs. The URL modification happens by tweaking the HTTP request completely or partially. GET and POST HTTP request verbs are more prone to it.
• ‍Obtaining unauthorized data access attack type permits an attacker to take control of the user databases storing crucial details. To perform the attack, a cybercriminal takes the help of key names and values. 
• ‍Performing unauthorized operations IDOR attack type refers to controlling the unverified user ID parameters API keys, and command names so that the attacker can perform an illegal action in the targeted system/application. Actions like forced password change, giving the crucial administrative command, and forced access to rate-limited APIs are included in this type of attack. 
• ‍Manipulating application objects attack is performed when an attacker gains permitted access to the internal object reference and is able to modify the fundamental details for application data. Success in this attack brings the power of modifying the session variables to the attacker. 
• ‍Getting direct file access is a typical IDOR type that co-exists with path traversal and permits an attacker to do easy file resource manipulation. Once successful, the attack empowers attackers to do quick file uploading, easy user data manipulation, and download paid content without bearing any expenses. 

All these above types of IDOR vulnerabilities are powerful alone and in combination with other vulnerabilities. 

Insecure direct object reference attack - Examples

IDOR, performed using the user-controlled parameter values, is very common and can be seen around us. Here are some of the IDOR examples.

• IDOR with direct reference to database objects

This is an IDOR occurrence possible and can be explained using an example. Just assume that there is a website taking the help of below-mentioned URL for the instant customer account page. 

https://insecure-website.com/customer_account?customer_number=132355 

The access takes place by recovering information stored in the back-end deployed databases.

In the example link, the customer number is consumed as a record index in back-end database queries. In case other controls are missing, attackers are allowed to modify the pre-mentioned value of customer_number and bypass the imposed access restrictions. Once this is done, they will be able to find out the information of other users. 

This example represents IDOR vulnerability causing the horizontal privilege escalation. Along with horizontal privilege escalation, vertical privilege escalation can also be done. In both cases, attackers have to modify the users using extra privileges so that access controls can be bypassed easily. 

The job can also be done using techniques such as exploiting password leakage and altering the key parameters when attackers have managed to barge into the user account. 

• IDOR with direct reference to static files

The presence of undetected sensitive resources in the static files also gives birth to the possibilities of IDOR vulnerabilities. 

A real-time example of this possibility is the website that is storing the chat message details/transcripts to disk. The file, storing the chat messages, is named using the incrementing filenames and permits end-users to retrieve any chat details using a URL as mentioned below. 

https://insecure-website.com/static/12144.txt 

Using this URL, a threat attack can easily alter the filename details so that the included chat message transcript and other crucial data can be accessed. 

‍

Detecting IDOR

The earlier is the detection, the lesser is the damage. Gladly, there are multiple ways to do early and accurate detention and testing for insecure direct object references. Some are manually powered while others are fully-automated. Let’s learn about them. 

• Fuzz Testing

It is a traditional vulnerability detection technique designed to spot any direct or indirect system malfunctions/failure when the intended program/software/application features any malformed entry/record. Applications using Swagger for API defining can use the Fuzz Lightyear tool for timely IDOR detection.

• Pen Testing

The next viable IDOR detection technique is using penetration testing on the intended application. This is the best approach for accurate, timely, and extensive detection. Burp Authorize is a very common and useful tool to use in penetration testing.

IDOR vulnerability Mitigation and prevention

It’s certain that not giving due attention to this loophole will lead to endless hassles. Hence, prevention, early detection and mitigation are highly essential. 

The very first and basic IDOR vulnerability prevention strategy is to replace the vulnerability-prone direct objects with their corrosponding indirect references so that threats are automatically away. If that doesn’t sound convincing, one can use secure hashes as replacement. This narrows the scope for threat actors, helping in insecure direct object references prevention.

Both these prevention strategies are useful to conceal the internal implementation but fail to identify the hidden access control problems. Those who are looking for an advanced approach can use extensive session management as this approach keeps the attacker away from accessing the authorized resources even if the IDOR attack is successful.