Insecure Direct Object References

Insecure Direct Object References was a category first seen in the OWASP Top Ten 2007 list. It retained its position on the following two succeeding Top Ten lists released in 2010 and 2013. Insecure Direct Object References tend to be prevalent, are easily detected, can be easily exploited, and can have a moderate, if not severe, impact on an organization upon successful exploitation.

An Insecure Direct Object Reference is essentially a vulnerability that involves breaking the access control limitations of an application to obtain access to unauthorized resources by directly referencing an object. Therefore, the vulnerability is the result of not properly enforcing access control. Personally, I see this vulnerability being most prevalent in the form of numeric values within parameters.

Suppose an application uses a backend database to store customer data such as contact information. The backend relational database uses a numeric value called a primary key to correlate records across multiple tables. The primary key is incremented by one for each record set. Although it is rather unsafe, an application may utilize this primary key to retrieve customer specific information from the backend database. If an attacker queries one customer and notices the value 15000 within a parameter upon intercepting the HTTP request being sent to the server, and then subsequently queries another customer record and notices the value is 15001, it would be relatively easy to quickly determine that the application likely would allow the user to access records they are not authorized to access by simply configuring a number list and injecting the parameter with a series of numeric values.

Let’s review another example of an insecure direct object reference. Suppose an application is designed to retrieve resources via a parameter in the URL (https://example.com?page=resource1.php). A standard user only has a set of links they are exposed to via the web application’s GUI. Even though a link to the resource admin.php does not exist, the user may still be able to query the page and access or modify its contents by changing the value within the page parameter from resource1.php to admin.php (https://example.com?page=admin.php). This type of attack is known as local file inclusion (LFI) because the resource is on the local file system of the target application. Additionally, this vulnerability can be leveraged by an attacker to exploit remote file inclusion (RFI) vulnerabilities as well. RFI is like LFI but instead of the resources being local, it’s a remote, external resource on a different server.

Let’s review some examples of insecure direct object reference vulnerabilities using two different inherently vulnerable web applications, bWAPP and Mutillidae II.

bWAPP

Scenario 1:

During the registration process, a user is required to select a username, password, and secret. Each user can change their secret or reset it. When a user submits their new secret, three parameters are passed to the server using the POST method. The first parameter ‘secret’ is the secret the user provided. The second parameter ‘login’ is the user’s username. The third parameter ‘action’ is configured to the value ‘change’. The insecure direct object reference vulnerability that exists, in this scenario, is associated with the second parameter ‘login’. If we change the value of this parameter to a username of a different account, we change the secret of a different user.

Figure 1: IDOR New Secret Input Field in Browser

Figure 2: IDOR Secret Change Original HTTP Request Parameters

Figure 3: IDOR ‘login’ Parameter Value Modified

Figure 4: IDOR Secret Change Response in Browser

Mutillidae II

Scenario 2:

Now that we have reviewed an example of Insecure Direct Object Reference vulnerabilities within bWAPP, let’s review an LFI related example using a directory traversal in Mutillidae II. A directory traversal attack would involve an attacker simply traversing to a lower level directory, to gain access to restricted resources. Mutillidae II uses the ‘page’ parameter to retrieve files. In this example, we’re going to retrieve the contents of the passwd file, which resides in /etc, outside of the web root folder (/var/www/html).

Figure 5: IDOR Page Parameter Original HTTP Request

Figure 6: IDOR Page Parameter Value Changed HTTP Request

Figure 7: IDOR passwd File Contents Retrieved and Rendered in Browser

Hopefully this blog post has helped you gain a better grasp on some of the risks that this vulnerability possesses. Exploitation of this vulnerability is rather easy and simple. The problems that could result from successful exploitation of IDOR vulnerabilities could potentially be devastating to an organization.

Originally authored by Ryan