What are IDOR (Insecure Direct Object References)? Attacks, exploits and security best practices

IDORs (Insecure Direct Object References) are widespread vulnerabilities in web applications in the same way as XSS or SQL injections. Affiliated with broken access control, IDOR vulnerabilities are indeed among those we most commonly discover and exploit during our web application penetration tests.

Principles, attack scenarios and exploits, we present in this article an overview of IDORs, as well as the best security practices and rights control tests to be carried out to prevent the risks.

What is an IDOR vulnerability?

An IDOR vulnerability is a rights control issue, which occurs when a direct reference to an object (files, personal information, etc.) can be controlled by a user.

Very often, this type of vulnerability allows to grant privileges horizontally (i.e. to access information of users with the same rights) and, in rarer cases, to escalate its privileges.

For example, let’s take the case of a SaaS application that includes invoice reading and writing functionalities, with predefined access and therefore user rights.

Now imagine that the rights controls are misconfigured, which would allow a user to access (read and/or write) the invoices of other users of the application simply by modifying the URL.

Indeed, the user could consult one of his invoices via the following URL:

https://www.example.com/invoices/002546

And then, with or without the help of a tool, he could modify the URL parameters. It should be noted in passing that this type of exploitation is very easy with a brute force tool, for example, for reasons of speed and parameter configuration.

Let’s take the simplest case here, i.e. changing the identifier of your invoice.

https://www.example.com/invoices/002746

If this file is indeed available in the database (via this ID) and no rights check is performed, it is referred to as an IDOR. In fact, the impact of this type of vulnerability can be critical depending on the sensitivity of the data.

Best practices to prevent IDOR vulnerabilities

To prevent IDORs, two approaches can be taken:

• Using indirect references

• Performing access control checks

Using indirect references

In this case, it is a matter of making the web application provide a user with URLs and associated parameters that only make sense in that user’s session.

Let’s go back to our example: the user will be able to access invoices using a URL of the type:

https://www.example.com/my-invoices/36

But depending on who is logged in, the same URL will not display the same invoice, making it impossible to gain unauthorised access to other users’ invoices.

Indeed, within the application, the URL https://www.example.com/my-invoices/36 will refer to an invoice which does not have 36 as an identifier, but can be ffc61035-b579-44e0-b7fc-199bb005cdde. Furthermore, this identifier must be generated randomly and must be long enough for the protection to be effective.

Thus, the correspondence between the indirect reference 36 and the invoice remains invisible to the user.

However, care must be taken in implementing this solution. The mistake would be to allow the user to enter a direct reference instead of an indirect reference.

The most common example concerns access to personal information. Many applications use endpoint/me to return a user’s personal information.

In this case, the server will then look at the session token of the requesting user to deduce the reference to the object associated with that account. If an attacker provides an identifier directly in the URL, he can in some cases bypass the control in place over the session token and thus access other users’ data.

Let’s imagine the following URL https://example.com/infos/me which returns the data of a user. For a user with ID 1340, the server can also accept https://example.com/infos/1340 to return the same information.

Here, an IDOR can occur if no other access control check is performed, as an attacker would only need to make a request to https://example.com/infos/1341 to access another account’s information.

The use of an indirect reference therefore forces the server to look at the session token or cookies. In fact, the session token must not be falsifiable to avoid any risk of IDOR or even account takeover in this case.

Performing access control checks

Using indirect references is not always possible. However, it is possible to use random characters for references, making it much more difficult to guess URLs. However, in many situations it will be necessary to control access rights to a given resource.

Let’s go back to the example of our application. If the application includes a functionality for sharing invoices, the URL should be the same for several users in order to facilitate exchanges, but should not be accessible to everyone.

In this case, an access control mechanism should be implemented.

The sharing URL could for example be:

https://www.example.com/invoices/bruce/dga7asg5s0sbaeaa7sba

And trying to access that URL will have to trigger checks to ensure that access is authorized. Indeed, you should not rely solely on having a random and long identifier.

What we think is a completely random identifier may not be so random. Let’s take the following identifier to illustrate our point:

001Do000002LlTAIA0.

Here (case encountered during a penetration test), the first 5 characters describe the type of object (such as “Account”), the next 5 are reserved for possible additional features and the last 5 are a unique identifier. The randomness is then greatly reduced and the brute force possibilities of the identifier are well present.

Moreover, even if the two conditions (unguessable and long) are met, care must be taken to ensure that the identifiers do not leak into the application.

For example, we have already seen that when an account is created, the identifier – in this case an email – ends up in the server response if the email is already in use. The attacker therefore only needs to target an account with an email address he knows to obtain information if the access control check is not correctly performed.

Finally, there is a specific case where IDORs can appear: when an application needs to share a link to a user without an account and therefore not authenticated. Unauthenticated access is then necessary and the only possible protection lies in the chosen identifier. Thus, the solutions recommended above must be implemented.

To further reduce the risk, rate limiting can be implemented on each sensitive endpoint.