The insecure direct object references vulnerability allows an attacker to steal other users’ data of a specific type. Beyond just the data in a database, an attacker can exploit it to access restricted files or directories on the server. According to the Open Web Application Security Project (OWASP), an insecure direct object references vulnerability is commonplace and easy to exploit.
So, what makes an application vulnerable to this attack? As the name indicates, it is caused when a direct reference (such as a database ID or a filename) to a restricted object is exposed to users as part of the URL parameter. In addition, the application fails to verify whether the user is authorized to access the requested object for which the reference is present in the request URL.
Let’s examine some specific attack vectors and ways to mitigate them.
In this exploit, attackers manipulate the identifier in the request URL to access other records in the database that do not belong to them. For example, consider this URL on a vulnerable application:
In this URL,
3032 is an ID of a profile record in the database. Because it is exposed in the URL and predictable, an attacker can simply change it to some other value and access other users’ restricted profiles.
Here is an another example of using a URL to retrieve a filesystem resource:
name parameter in this URL specifies the exact filename to retrieve. Attackers can modify this predictable parameter to access reports for other months, for which they have neither paid nor are subscribers.
The following subsections present some concrete measures to prevent insecure direct object references.
Instead of requiring the references in the URL, use the information already present in the user’s session on the server to locate the resources to serve. For example, in the
www.example.com/profile/3032 route implementation we just reviewed, if the users are allowed to access only their profile, we can use the logged-in user’s ID in the session to locate it, thus eliminating the need for passing
id as a URL parameter.
If it is not possible to avoid exposing the references to objects in the URL, as explained earlier, the indirect reference map technique is helpful. The idea behind it is to substitute the sensitive direct internal reference in URL parameters or form fields with a random value that is difficult to predict (such as a GUID) or specific only to the logged-in user (such as sequential values per user or session).
The OWASP Enterprise Security API project provides a good reference implementation for indirect reference map in Java to get a better idea of how to implement it.
This defense mechanism addresses the primary issue causing the vulnerability: an insufficient or missing access check.
First, never rely only on client-side validations for access control, because an attacker can easily circumvent those.
Second, while implementing the server-side access controls, it is relatively obvious to add authorization checks at the functionality or route level. Unfortunately, many applications stop at that level. A common issue that causes this vulnerability is missing access checks at the data or object level to protect against tampered IDs in URL parameters. You need to enforce the data layer access controls by verifying that the current user owns or is allowed to access the requested data.
The directory traversal is a special case of the insecure direct object references vulnerability, in which an attacker manipulates the path exposed in a URL to access directories and files outside of the web root folder and possibly compromise the entire web server.
To exploit it, an attacker uses absolute or relative path traversal characters such as
../, or its encoded versions
%2e%2e/ to manipulate the path.
To prevent the directory traversal attack, you need to take measures at the system-configuration as well as the application-code level:
At the system-configuration level, configure the root directory and access control list to confine the application user’s access and restrict access to files and directories outside of the web root.
In the application code, validate user inputs for presence of path traversal and corresponding encoded characters.
The internal references to objects such as database IDs or filenames are often exposed publicly as part of the URL parameters. The techniques to prevent insecure direct object references primarily focus on protecting these references as sensitive data and checking access control at the data-object level.