What is an Insecure Direct Object Reference (IDOR)?

As promised, we are back with our next blog about the top reported vulnerabilities!

In this blog, we are casting light on the Insecure Direct Object Reference (IDOR) vulnerability. We will discuss what kind of vulnerability is that, how the attacker is retrieving the information, what are the impact and the gradient of severity, as well as how this vulnerability can be prevented and mitigated.

What is an IDOR?

An IDOR, or Insecure Direct Object Reference, is a vulnerability that gives an attacker unauthorized access to retrieve objects such as files, data or documents. Moreover, this vulnerability is listed in the 2021 OWASP top ten under broken access control.

IDOR vulnerability often occurs under the false assumption that objects will never be retrieved directly using their unique identifier, but merely through the application logic. Usually, an application will show you only the objects you are authorized to view and often provide you with the required identifiers to retrieve those. However, upon retrieval of the said object, a check, if the requesting user is actually allowed to access the object, is often missing.

In the example below (Figure1), the vulnerable object can be found in the URL. By modifying the number to different existing IDs the attacker can retrieve the information of that page belonging to the victim.

Other places that can contain vulnerable objects are anywhere in the application that accepts user input to reference objects directly. To test this, a value needs to be changed. When there is no verification of whether a user is authorized to retrieve this data, data will be returned.

In order to find IDORs, the method that can be used is to create 2 accounts for an application and capture the HTTP requests with Burp Suite, or another proxy. These requests can be compared and the string that is different could be an IDOR, as this is a unique value to the user. The test to verify whether this object is vulnerable is to repeat the request from one user in the context of the other user and see if data is returned.

Impact

There are different things that can happen depending on the parameter that was changed, as well as the impact is dependent on the type of data. An IDOR vulnerability can lead to:

Access to sensitive data (Confidentiality).
Unauthorized alteration or deletion of data (Integrity and Denial Of Service).

Severity

The severity of an IDOR depends on the impact. The vulnerability will have a higher severity where the attacker can use the IDOR to take over an important account, compared to the cases where access to unimportant information is found. Examples of severity with IDOR are:

Critical‍

Taking over an admin account.

High

Taking over another user’s account.

Medium

Being able to view another user’s information.

Low

Finding access to restricted data, though this can be higher depending on the kind and sensitivity of this data.

Informational

Finding access to restricted, but unimportant, data.

Preventing IDOR

Access control

Authentication is the process of verifying and identifying a user. Authorization is specifying the access rights/privileges this user has. An IDOR often occurs when the authorization is not validated with the requested resource before the resource is released or changed.

To prevent resources from being shown to or changed by the wrong user, access control must be applied. This is done by verifying that the user has legitimate access to the resource in question.

It is good practice to deny all access to resources by default unless it is public information. This will prevent the wrong information to be shown to users that should not have access.

Mitigating

Use an object identifier that is not easily guessable

Don’t give objects a value with a number or easily guessed word, instead use a hash with salt. By only hashing the value of an object can be cross-referenced with other values and guessed by attackers. For example, the hashed word ‘Value’ will always be the same.

‍

Value = 8185923e0830e44b21d1c6c8c43fa895374fdbb40f9200572d13b58fcdd2a2df

By adding salt every value will have a unique string making it even harder to guess.

Value + GKLBP = 821becddd1ffb3c1dadcbac63c5a728a223a2c7cdbfc225930afc44f1ebb861e

Value + PRCUQ = a9fd81c209f334aa8e7826a50ba9a06f90c2dc822df38416a8f2ab7f4c55f5cd

Value + WZTJY = a1e1b47e447099f48da6c863f887f53e8299eae2dbc8c9a5dd46f2a9144d8e84

An even easier way to achieve this is by using randomly generated values for objects, such as a Universally Unique Identifier (UUID).

We hope you find the information useful and enjoyed the blog! If so, stay tuned for the next blog on top reported vulnerabilities! Have you missed the first blog about Cross-site scripting (XSS) vulnerability or would like to refresh a memory? You can still check it here.

‍