Insecure Direct Object Reference (IDOR) is a very common flaw in application authorization logic. The potential damage from the operation of IDOR vulnerability can be both minimal and critical. Let’s look at some cases where the presence of IDOR made it possible to implement a high-risk threat – an account hijacking or a project hijacking.
Account hijacking gives the attacker full or nearly full access to the victim’s account.
Hijacking a project gives the attacker access to a separate project created within the user’s account. Often, an attack does not completely hijack an account, but it is possible to hijack some resources belonging to another user (for example, a project or an internal user created by the administrator). I have repeatedly encountered similar vulnerabilities in Bug Bounty programs.
What is this IDOR?
IDOR is an unsafe direct object reference. This shortcoming is often explained by the example of the support service interface, where, by changing the ticket ID, you can read the tickets of other users. But in fact, IDOR is not limited to changing the numeric identifier for reading data, the result of an attack can also be a change in data.
There are also cases where it is difficult to find out the ID, if it is, for example, a hash or uuid, in this case the risk is greatly reduced. But in my practice, I almost always managed to find ways to find out the victim’s ID.
I think IDOR can be divided into subtypes. By the nature of the action:
- Reading data
- Data change
- Privilege escalation (a special case of data changes)
- Account hijacking (special case of privilege escalation)
Let’s look at an example of using IDOR to capture an account or project.
IDOR leads to Account TakeOver
How, after all, with the help of IDOR it is possible to capture an account or any other entity that is created within the account itself (most often this is an internal project)? For example, a user creates a manager or some kind of project in his account, and an attacker can take control of these entities / objects.
In the case of hijacking the main account, it is not so easy, because the attacker usually cannot directly access the main account from his account. The capture of the main account occurs through the entities of the account, for example, through some project or the same manager. Below we will look at specific cases from Bug Bounty.
IDOR when adding and deleting a project in a group
There are projects where there are different tariff plans that can be connected for a certain cost. There is also a special Enterprise tariff that adapts to the client depending on his needs. In one of the projects, when the Enterprise tariff was connected, ordinary projects could be added to it in a group, and then they also received the Enterprise status.
IDOR was found in two places at once. When adding a project to the Enterprise group, as well as when deleting it. When adding, everything was trivial: a POST request was sent with a JSON body, which transmitted the name of the project, which is open to everyone, so you could add someone else’s project to your group and gain control over it:
| 1234 | POST /api/projects/victim/children HTTP/1.1Host: victim.com {“subdomain”:”victim1″} |
It was more difficult with IDOR when deleting a project. The very process of removing a project from a group was implemented logically incorrectly. When deleting a project, a POST request was sent, in which the full description of the group was transmitted in a serialized form, but at the same time the identifier of the project whose deletion was requested was removed from it.
In this case, it was possible to simply add or change the project ID, which was still in the group, to the ID of someone else’s project.
The exploitation was complicated by the fact that the ID was a random value, which could not be picked up or guessed. But it turned out to find a way to find out the project ID through the frontend: you could go to the project page (the pages are public) and find the ID in JSON format in the page code:
I managed to find the project ID at the front
Final query:
| 12345 | PUT /api/projects/victim HTTP/1.1Host: victim.comCookie: … {“childrenProjects”:[“id_project1″,”id_project2″,”id_project_victim”]} |
IDOR when transferring a manager
This attack exploited 2 vulnerabilities at once, resulting in a very high level of risk due to the chain. This is an incorrect configuration of access ( Improper Access Control ) and IDOR.
Due to incorrect access settings, it was possible to view other people’s projects and managers who were attached to these projects. This vulnerability has already made it possible to steal some confidential data.
But in the course of further study of the application, another drawback was discovered, which allowed, when saving the profile of your account, to connect to the account also someone else’s manager by his identifier (so this is IDOR).
It was possible to find out the ID through the previous vulnerability. By connecting someone else’s manager to his account, the attacker received the privileges of this manager and gained control over his project. The gained access allowed him to view and edit the data.
We are talking about the vulnerability described in the report https://hackerone.com/reports/863983 . The vulnerability allowed access to the data of more than 1 million drivers: passports, driver’s licenses. Also, by hijacking the partner’s account, the attacker could change the data of drivers who were registered with the help of this partner (taxi fleet).
Total
More than $ 25,000 was paid for the vulnerabilities described above, and the potential damage from the actions of cybercriminals could be many times greater than this amount.
To avoid such losses, timely conduct a security analysis of your projects. Contact us for security analysis and penetration testing services .