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/002546And 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/002746If 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.
For more information, we refer you to this Write-Up in which we present a concrete case of a multi-tenant exploitation of GraphQL via an IDOR:
Exploiting a broken access control vulnerability on GraphQL
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/36But 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/dga7asg5s0sbaeaa7sbaAnd trying to access that URL will have to trigger checks to ensure that access is authorised. 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.
How to evaluate access control checks and identify IDORs?
Access control tests are an essential step in a penetration test, especially as there are regular vulnerabilities in this critical mechanism. For a web penetration test, BURP is perfectly suited to perform these tests. And for this purpose, two extensions are available: AuthMatrix and AuthAnalyzer.
The common principle of these extensions is to replay requests that might have rights issues with different session tokens. In general, we use an account with the highest rights (often an administrator), an account with simple user rights and an unauthenticated user.
Thus, the extension will replay all requests with the different session tokens provided. A colour code then allows us to identify any broken access control.
In the example below, 3 different sessions have been provided to AuthMatrix: admin, collaborator and an invalid session token – unauthenticated.
To come back to the specificities of the 2 extensions. On the one hand, we have AuthMatrix which allows a more precise selection of queries to be analysed. This extension is useful when there are few queries to study or when sensitive queries (such as queries that can create, modify or delete data) should not be replayed. Also, this extension allows you to test for CSRF vulnerabilities.
AuthAnalyzer is more convenient when many requests need to be checked. After configuring the sessions we want to use, the extension will replay all requests we make from our browser with the session tokens provided.
Below is the interface of AuthAnalyzer in Burp, with the same 3 accounts of the example with AuthMatrix. There are 3 types of responses: SAME revealing that the response is identical to the response obtained with the original request account, SIMILAR meaning that the body of the response is similar but the data is not identical and DIFFERENT showing a big difference between the basic response and the one obtained with the account in question.
Conclusion
Rights management remains a delicate exercise. Indeed, despite configuration tests, it is not uncommon to find IDOR vulnerabilities during a penetration test. However, there is no automated tool that can easily identify them because you need to understand the logic of an application to know if the server is performing the right access check or not. However, to test the possibilities of bypassing access control checks, Burp’s extensions (AuthMatrix and AuthAnalyzer) are essential.
Author: Julien BRACON – Pentester @Vaadata