99% of what I do is exploiting avoidable mistakes. Today I'll talk about IDOR, one of the most common and easy-to-exploit web vulnerabilities. It can be used to view someone else's photos on social media, get a discount on an online store, or earn thousands of dollars in bug bounties.
Using real-world examples, I'll show how hackers find and exploit business logic errors in applications and give practical advice on how to fix them during the development stage.
The user is expected to manipulate objects through the interface, within the app's logic. The app only displays those objects with which the user is permitted to interact. However, an observant user will notice the identifiers of these objects, for example, in the address bar. A hacker will inevitably try to change them. This allows access to other objects directly, bypassing the app's logic and violating any restrictions.
This vulnerability is called IDOR (Insecure Direct Object References). It occurs when three conditions are met simultaneously:
By crunching numbers, you'll eventually guess a link to someone else's draft, like this one: https://habr.com/ru/company/bastion/blog/686516/ . If the link opens, congratulations, you've found IDOR. This doesn't happen on Habr because the third condition required for IDOR to appear isn't met. Habr has a proper authorization mechanism.
URL modification is a classic example of an IDOR, but vulnerable identifiers aren't limited to the address bar. Based on HackerOne bug report statistics , IDORs are most often found in REST APIs, GET parameters, and POST request bodies.
I recently encountered a similar error on a new social network portal. When accessing the GET /feed/gallery/uuid endpoint, the server returned users' personal information: phone number and email address.
In this example, the DELETE /accounts/{uuid} method is available without authorization, allowing the deletion of an arbitrary user account by specifying a valid UUID. Typically, this identifier has high entropy and is difficult to brute-force, but when combined with other vulnerabilities, this IDOR is very dangerous.
In this case, unauthorized access to several endpoints containing the page_size parameter was possible on the resource under investigation. This parameter is responsible for displaying user pages. Correctly modifying the request allowed for bulk and unauthorized extraction of user information, including the UUID required for IDOR exploitation.
This is a screenshot from a pentest of a delivery service. It turned out the app had access to an API intended only for company employees. IDOR provided the client with full employee functionality, such as viewing vehicle status and creating new accounts.
One such unauthorized access was found on an online school's website, allowing access to curriculum and lessons. To download the content, all one had to do was access the following routes: /api/0/curriculum/lessons/ and /api/0/files/<id>/content.
To find IDOR:
In BURP Suite, such checks are partially automated using plugins such as AuthMatrix or Autorize . They eliminate routine work and allow filtering of results (for example, in Autorize, using the "Scope items only" flag and regular expressions). However, these plugins are merely a convenient tool; the key to this type of bug hunting is experience and an understanding of how the application works.
Try replacing GET with a different HTTP method. If that doesn't work, add the Content-length HTTP header or change the content type.
The problem is that IDORs are tightly intertwined with the application's business logic. The only way to reliably eliminate IDORs is to carefully configure session management and user access checks at the object level. This way, even if an attacker finds and modifies an internal link, they still won't gain unauthorized access.
Of course, every application is different. There's no one-size-fits-all approach to implementing access control, but the mechanism should be well-designed and tested using specific patterns.
It's worth testing a scenario in which a low-privilege user attempts to perform actions intended only for high-privilege users. The verification scheme is similar to that used in a hack.
Using real-world examples, I'll show how hackers find and exploit business logic errors in applications and give practical advice on how to fix them during the development stage.
IDOR - what is it and how to use it
Let's start with the basics. A web application manipulates certain entities. For example, on an online store website, these entities include products, users, shopping carts, promo codes, and so on. Each instance of such an entity is treated as a separate object and assigned its own identifier. ID 483202, pid 6260—every application is populated with such values.The user is expected to manipulate objects through the interface, within the app's logic. The app only displays those objects with which the user is permitted to interact. However, an observant user will notice the identifiers of these objects, for example, in the address bar. A hacker will inevitably try to change them. This allows access to other objects directly, bypassing the app's logic and violating any restrictions.
This vulnerability is called IDOR (Insecure Direct Object References). It occurs when three conditions are met simultaneously:
- the user can find a direct reference to an internal object or operation;
- the user can change the parameters in this link;
- The application provides access to an internal object or operation without checking user permissions.
By crunching numbers, you'll eventually guess a link to someone else's draft, like this one: https://habr.com/ru/company/bastion/blog/686516/ . If the link opens, congratulations, you've found IDOR. This doesn't happen on Habr because the third condition required for IDOR to appear isn't met. Habr has a proper authorization mechanism.
URL modification is a classic example of an IDOR, but vulnerable identifiers aren't limited to the address bar. Based on HackerOne bug report statistics , IDORs are most often found in REST APIs, GET parameters, and POST request bodies.
Risks and consequences of IDOR
The severity of vulnerabilities of this type depends heavily on the data and operations available to the attacker. IDORs are conventionally divided into four types (in practice, they often overlap):1. Obtaining unauthorized access to data
Sometimes direct references to objects provide access to database contents: individual fields or internal identifiers, which can be used to prepare SQL injections.
I recently encountered a similar error on a new social network portal. When accessing the GET /feed/gallery/uuid endpoint, the server returned users' personal information: phone number and email address.
2. Performing unauthorized operations
By changing your user ID or API keys, you can access paid app features and even run commands as an administrator.
In this example, the DELETE /accounts/{uuid} method is available without authorization, allowing the deletion of an arbitrary user account by specifying a valid UUID. Typically, this identifier has high entropy and is difficult to brute-force, but when combined with other vulnerabilities, this IDOR is very dangerous.
In this case, unauthorized access to several endpoints containing the page_size parameter was possible on the resource under investigation. This parameter is responsible for displaying user pages. Correctly modifying the request allowed for bulk and unauthorized extraction of user information, including the UUID required for IDOR exploitation.
3. Managing application objects
Some IDORs allow editing of data within the application. This vulnerability allows an attacker to modify session variables, for example, to escalate privileges or gain access to restricted functions.
This is a screenshot from a pentest of a delivery service. It turned out the app had access to an API intended only for company employees. IDOR provided the client with full employee functionality, such as viewing vehicle status and creating new accounts.
4. Direct access to files
This type of IDOR allows you to manipulate file system resources: upload and edit files, download paid content for free.
One such unauthorized access was found on an online school's website, allowing access to curriculum and lessons. To download the content, all one had to do was access the following routes: /api/0/curriculum/lessons/ and /api/0/files/<id>/content.
Collect Them All! Or How to Hunt IDOR
To find IDORs, hackers intercept API requests and substitute new identifiers into them using a web proxy, such as BURP Suite . Sometimes they rely on luck and brute-force IDs, but there are also more sophisticated techniques, such as session tag exchange.To find IDOR:
- You need to create two users and save their session tags.
This could be a token or a session ID—any string in the API that the application uses to identify the logged-in user. - The next step is to log in as the first user, perform a series of actions in the application, and record them using a proxy.
- Now you should look at the traffic and find the API call in which the object ID is passed to the server.
- You need to repeat the call, intercept it, edit it, and send it to the server with the second user's session tag.
In BURP Suite, such checks are partially automated using plugins such as AuthMatrix or Autorize . They eliminate routine work and allow filtering of results (for example, in Autorize, using the "Scope items only" flag and regular expressions). However, these plugins are merely a convenient tool; the key to this type of bug hunting is experience and an understanding of how the application works.
- It is necessary to find out what roles and groups are provided in the application and how they interact.
What is the difference between a manager, driver, and administrator, and what functions are available to each? - It is advisable to build a map of the relationships between resources.
How are orders, receipts, and products related? Can one user place orders under someone else's name? - It's worth exploring the features of the REST API.
This set of rules forces developers to act in a formulaic manner, and this can be used against them. Let's say you've found an endpoint that exposes a REST resource.
Try replacing GET with a different HTTP method. If that doesn't work, add the Content-length HTTP header or change the content type.
Why is there so much IDOR?
In the last few years, IDORs have become ubiquitous, appearing in multiples within even the smallest apps. I believe there are objective reasons for this:- More identifiers are being sent from clients.
Previously, the server could directly track user actions, but in modern applications, clients transmit increasingly more data per request through APIs. - Old IDOR protection techniques are no longer used.
Developers often replaced real object IDs with temporary ones, relevant only to a given user and session. To achieve this, a separate table was created on the backend, where each object was assigned a temporary ID. This practice is no longer relevant because it doesn't align well with REST API principles. Furthermore, this interface no longer provides for recording client state (stateless). - Role models are becoming more complex.
Even if an application has a robust user rights verification mechanism built into it, it needs to be configured correctly. It can be difficult for a developer to determine whether user X has access to file Y, especially if the user is a regional manager, who belongs to one of a dozen subtypes within the role model. Miscommunication between developers and end users further complicates the authorization mechanism setup. As a result, users are often given redundant permissions simply to avoid accidentally removing the functions they need.
Protecting yourself from IDOR is not the same thing.
There are many recommendations online for combating IDOR, but many of them are confusing. The authors of such advice often list methods for mitigating the vulnerability's risk and present them as ways to fix it. I'm referring to recommendations such as:- Using random identifiers.
Most programming languages include cryptographic functions that generate new values with high entropy. Using these to create object identifiers makes it more difficult for attackers to guess a new ID to exploit IDOR. - Using hashes.
Another way to make identifier spoofing more difficult is described in the OWASP memo , for example . However, hashes can be brute-forced. Incidentally, Base64, which is sometimes used for this purpose, although it is not a hash function, is decoded without any problems. - Using JWT JSON Web Tokens.
Such tokens protect against some manipulations with user identifiers, but do not solve the problems with object identifiers. - Filtering user input before it is processed by the application, checking ranges, lengths and formats.
Perhaps the most useful of the listed recommendations, the main thing is to set up the filter correctly.
The problem is that IDORs are tightly intertwined with the application's business logic. The only way to reliably eliminate IDORs is to carefully configure session management and user access checks at the object level. This way, even if an attacker finds and modifies an internal link, they still won't gain unauthorized access.
Of course, every application is different. There's no one-size-fits-all approach to implementing access control, but the mechanism should be well-designed and tested using specific patterns.
It's worth testing a scenario in which a low-privilege user attempts to perform actions intended only for high-privilege users. The verification scheme is similar to that used in a hack.
- Log in to the application using an account with the highest privileges.
- Perform a series of actions in the application and record requests to the API using a proxy.
- Authenticate to the application using a lower-privilege account to generate a token for the Authorization header.
- Replay recorded API requests with a modified header using a low-privilege user token.
- The user is not authenticated, for example, the Authorization header is missing or invalid.
- The user is authenticated but not authorized on the resource.
