Security has become a major concern in the digital age for businesses, governments, and individuals alike. One of the security vulnerabilities that organizations face is Insecure Direct Object Reference (IDOR). Application developers can fall victim to this vulnerability when they fail to authenticate users and authorize specific resource requests. What exactly is IDOR, and why is it crucial for developers to understand and avoid this vulnerability? In this article, we will delve into the details of IDOR and explore ways to prevent it.
What is IDOR?
IDOR is a vulnerability that occurs because of broken access control where users can access internal objects directly. IDOR is one of the security holes that many attackers take advantage of because it is one of the most common in modern web applications.
In such cases, an attacker is able to access information that is not intended to be accessible to them, including resources and data of other users with similar privileges (known as horizontal privilege escalation). However, in more severe instances, attackers may gain access to confidential data that is only meant to be accessed by the website owner or administrator (referred to as vertical privilege escalation).
Examples of IDOR
Take a look at the URL below.
https://example.com/account?user=1256
Assuming we have logged in to a website and retrieved an ID value of 1256 from the URL. In cases where the website has poor access control measures in place, a user can easily manipulate the parameters in the URL to gain access to the information of another user by changing the value to, for instance, user=1257. This is a classic example of horizontal privilege escalation, where an attacker exploits IDOR.
However, the extent of the breach could be more severe. An attacker could attempt to gain access to the admin account by changing the ID value to user=administrator. If successful, the attacker could gain administrative privileges, thereby escalating the breach to vertical privilege escalation.
IDOR prevention
Session and JWT
As previously mentioned, IDOR vulnerabilities arise from weaknesses in access control measures. To mitigate the risk of IDOR attacks, it is essential to have a fundamental understanding of authentication, session management, and access control.
Authentication is the process by which a website verifies a user’s identity to ensure that they are who they claim to be. This is typically achieved through a login form.
Upon successful login, the user is assigned a unique session ID or token that identifies their active session. It is crucial to ensure that the token is invalidated when the session ends or is only valid for a specific time period.
With proper authentication and session management in place, users can perform actions based on their assigned permissions, such as CRUD (Create, Read, Update, Delete) operations. These permissions should be granted based on the user’s authorized scope.
Now that we have a better understanding of these concepts, let’s take a closer look at how IDOR vulnerabilities can arise from a developer’s perspective. Consider the following PHP code as an example:
<?php
…
$user_id = $_GET['user_id'];
$user_data = get_user_data($user_id);
…
Assuming there is a function named “get_user_data()”, the developer may use this logic to retrieve the users’ data. This could be the reason why the application has the IDOR vulnerability. The developer directly refers to the user information with no verification process at all. The session management process is skipped, hence the server won’t be able to keep track of the currently active user. If the attacker somehow has access to this account, the server won’t know whether the request is being sent by the legitimate user or not.
From a security standpoint, it is better to use the following command.
<?php
session_start();
$user_id = $_SESSION['user_id'];
$user_data = get_user_data($user_id);
…
With this logic, the current user is identified by the session instead of directly referring to the user’s data. On the other hand, the server can track currently active users by verifying them with the session id. It also makes it more difficult for the attacker to get access into the account due to the unique id it requires to communicate with the server and at the same time eliminating IDOR vulnerability.
Alternatively, developers may choose to implement other authentication methods, such as using a JWT (JSON Web Token) that provides a unique token to the active user, without requiring the server to maintain a session between the client and server. Currently, this method is preferred due to its superior performance and security features.
UUID (Universally Unique Identifier)
In addition, the developer could also implement measures to increase the complexity of the user ID. Rather than using a simple numeric ID such as in https://example.com/account?user=1256, using a UUID (universally unique identifier) such as https://example.com/account?user=4274cec9-4af3-4bb9-8850-4d0c169f7616 can significantly increase security. Although IDOR vulnerabilities may still exist, using a UUID makes it considerably more challenging for attackers to enumerate possible user IDs, as UUIDs are designed to be unique and unpredictable.
However, it doesn’t make your application completely immune to the attack. The attacker may find other vulnerabilities in order to take this UUID, so making sure that you don’t leak any UUID from the server side is very critical.
Conclusion
There are so many web applications today that have an IDOR vulnerability today. IDOR occurs when an application exposes a direct reference to an internal object, such as a file or database record, without properly enforcing access controls. At the time this article is written, it is even listed as one of the top OWASP vulnerabilities as a manifestation of broken access control. To prevent such issues, it is imperative to enforce secure coding practices and conduct thorough security testing to address any potential Insecure Direct Object Reference (IDOR) vulnerabilities.