Insecure Direct Object References: a major threat to web applications
Insecure Direct Object References (IDOR) are among the most common and dangerous vulnerabilities in web applications. In this article, we will explore what IDOR is, how it works, why it is dangerous, and, most importantly, how to prevent it.
An IDOR is a type of vulnerability that is often underestimated or misunderstood by developers, but well-known to hackers and security researchers. In fact, IDORs have often been, and continue to be, the source of data breaches (see examples: Uber 2016, Microsoft Teams 2023). Furthermore, they appeared in the OWASP Top 10 for the first time in 2007 ("A4 – IDOR"). Since then, IDORs were merged into the "A7 – Missing function level access control (2013)" category and later into the "A5 – Broken Access Control" category in 2017.
In 2021, this category was placed at the top of the OWASP Top 10, confirming its importance, criticality, and high risk of occurrence. Finally, in the 2023 OWASP API Security Top 10, this category was split into three separate categories:
- API1 – Broken Object Level Authorization
- API3 – Broken Object Property Level Authorization
- API5 – Broken Function Level Authorization
Definition
A direct object reference occurs when it is possible to target a resource using an identifier or a name, for example. When it is possible to iterate through identifiers or names to target all relevant resources, and access control checks for those resources are poorly implemented or missing entirely, it is referred to as an Insecure Direct Object Reference.
In other words, if an application does not verify that the user is authorized to access a specific resource, an attacker can modify these references to access resources that do not belong to them.
There are several types of IDOR, often divided into four categories that allow:
- Read access to resources;
- Creating, editing, or deleting resources;
- Read access to documents;
- Access to features.
Read access to resources
Authentication is typically required to use an API route such as "/api/user/{user_id}/account". However, if no restrictions are in place to limit access to other accounts' information, it becomes possible to iterate through the "user_id" parameter value to retrieve every user's data.
Creating, editing, and deleting resources
The same type of vulnerability can affect a route like "/api/orders/comment": if no restrictions are in place to limit adding comments to other users' orders, it becomes possible to iterate through the "order_id" parameter value to add comments to any order.
Read access to documents
This is a specific case of the first category applied to documents. There are several types of vulnerable requests in this scenario: accessing documents using an identifier or accessing documents using a filename.
Local File Inclusion (LFI) vulnerabilities are a specific case of this type of IDOR.
Access to features
Consider a route like "/api/employees/?role=rh", which requires authentication. If no restrictions are in place to limit access to features reserved for specific roles on the employee list, it becomes possible to iterate through the "role" parameter value to access different views and features, eventually obtaining the view and features reserved for an administrator.
Specific cases
When applied to certain user account characteristics, IDORs can be highly critical for an application.
Modifying user roles
When an IDOR affects a user's role-change functionality, it may be possible to:
- Modify another user's role
- Elevate your own role
This can allow you to downgrade or elevate another user's permissions, or elevate your own privileges within the application.
Password change
When an IDOR affects a user's password change functionality, it may be possible to modify another user's password.
This can lead to the compromise of other users' accounts and potential privilege escalation within the application.
Remediation: protecting an application against IDOR vulnerabilities
To protect an application against IDOR vulnerabilities, here are some recommendations to follow:
- Systematically verify access rights to resources, taking into account both individual ownership and shared resources.
- Ensure that access rights to features are correctly managed based on user roles.
- Avoid direct references in parameters, particularly by limiting user input.
- Use UUIDs (Universally Unique Identifiers) to mask sensitive identifiers; while this does not guarantee the absence of IDOR, it makes exploitation more difficult.
- Always validate input from users to prevent any manipulation.
Conclusion
Insecure Direct Object References (IDOR) represent a serious threat to web application security, primarily due to their ease of exploitation and their ability to expose sensitive data. However, by applying strict access controls, using indirect references, and correctly validating authorizations on the server side, developers can effectively prevent these vulnerabilities.
