idor-theory

IDOR vulnerability occur when a web application exposes a direct reference to an object, like a file or a database resource, which the front-user can directly control to obtain access to other objects.

Building a solid access control system is very challenging, which is why IDOR vulnerabilities are pervasive.

This is why IDOR/Access Control vulnerabilities are found even in very large web applications, like Facebook, Instagram, and Twitter.

In addition, automating the process of identifying weaknesses in access control systems is also quite difficult, which may lead to these vulnerabilities going unidentified until they reach production.

There are many way to implement a solid access control system for web applications, like Role-Based-Access-Control (RBAC). The main takeaway is that an IDOR vulnerability mainly exists due to the lack of an access control on the back-end.

Impact of IDOR vulnerabilities

• The most basic IDOR vulnerability is accessing private files and resources of other users that should not accessible to us, like personal files or credit card, which is known as IDOR information disclosure vulnerabilities.

• IDOR vulnerabilities may give references to database IDs or URL parameters, attacker can start testing specific patterns.

• IDOR vulnerability may lead to the elevation of user privileges from a standard use to an administrator user.

URL parameters & APIs (Identify IDORs)

AJAX calls

• We should study the HTTP requests to look for URL parameters or APIs with and object reference (eg. ?uid=1 or ?filename=file_1.pdf).

• These are mostly found in the URL parameters or APIs and cookie header.

• We may find some hidden parameters in source code (AJAX calls).

Hashing/encoding

Sometimes web applications use encoding/hashing (base64) to hide parameters value instead using plain text values.

Compare user role

If we want to perform more advanced IDOR attack, we may need to register multiple users and compare their HTTP requests and objects references.

Mass IDOR enumeration

Exploiting IDOR vulnerability is easy in some instances but can be very challenging in others. For advanced IDOR attacks, we need to better understand how the web application works, how it calculates its object references.

curl -s "http://SERVER_IP:PORT/documents.php?uid=1" | grep "<li class='pure-tree_link'>"

curl -s "http://SERVER_IP:PORT/documents.php?uid=3" | grep -oP "\/documents.*?.pdf"

Using loop over the "uid" parameter

for i in {1..10}; do url="http://SERVER_IP:PORT"; for link in $(curl -s "$url/documents.php?uid=$i" | grep -oP "\/documents.*?.pdf"); do wget -q $url/$link; done; done

Insecure parameters

• We see some documents with predictable name in the address bar

• If we check source code of the web application, we may see some file with a predictable name, so we can try fuzzing file names.

• We must be attentive to the page details during any web pen testing

• This is a common mistake found in web applications suffering from IDOR vulnerabilities, as they place the parameter that controls which user documents to show under our control while having no access control system on the back-end.

e.g.,

• documents.php?uid=1

• Try to play with HTTP method

Encoded bypassing references

A web application is using md5sum, base64 to encode references values. We can try encoding like uid, username, filename values to match with existing hash to find out which hashing/encoding algorithm is being used by the web application.

e.g., contract=cdd96d3cc73d1dbdaffa03cc6cd7339b (MD5) Check out the source code to identify references/parameter, values and algorithm used by the web application to encode values;

Double encoding can be used as well

• Base64 > md5sum

Encoding command

echo -n 1 | base64 -w 0 | md5sum

We are using the -n flag with echo, and the -w 0 flag with base64, to avoid adding newlines, in order to be able to calculate the md5 hash of the same value, without hashing newlines, as that would change the final md5 hash.

Mass encoding enumeration

for i in {1..10}; do echo -n $i | base64 -w 0 | md5sum | tr -d ' -'; done

Test on website:

#!/bin/bash

for i in {1..10}; do
	for hash in $(echo -n $i | base64 -w 0 | md5sum | tr -d ' -'); do
		curl -sOJ -X POST -d "contract=$hash" http://SERVER_IP:PORT/download.php
	done
Done

IDOR in Insecure APIs

IDOR vulnerability can be found in insecure APIs and many actions such as delete, update, privilege escalation can be performed.

Identify insecure APIs

Try to explore web application features such as update profile information. Applications may use cookie to set use role or include data in the HTTTP request body. Try to play with parameters in URL, cookie, body data, change it to see behaviour of web app.

Possible vulnerable parameters:

Cookie
Role
UID
UUID
URL parameter

Exploit:

• You can create a new use by changing HTTP method to POST.

• Change the UID to access different user account.

• Escalate privileges - Play with role parameter, or change to admin, administrator.

• Test for APIs endpoints for IDOR vulnerabilities.

We see that the page is sending a PUT request to the /profile/api.php/profile/1 API endpoint. PUT requests are usually used in APIs to update item details, while POST is used to create new items, DELETE to delete items, and GET to retrieve item details. So, a PUT request for the Update profile function is expected. The interesting bit is the JSON parameters it is sending:

Exploiting Insecure APIs: We know that we can change the full_name, email, and about parameters, as these are the ones under our control in the HTML form in the /profile web page. So, let's try to manipulate the other parameters.

There are a few things we could try in this case: Change our uid to another user's uid, such that we can take over their accounts Change another user's details, which may allow us to perform several web attacks Create new users with arbitrary details, or delete existing users Change our role to a more privileged role (e.g. admin) to be able to perform more actions

Chaining IDOR vulnerabilities

Changing use details, thus allowing us to take control over their account. Another potential attack is placing XSS payload on any field, which would get executed once the user visits their edit profile page.

Chaining two IDOR vulnerabilities

• Once you identified a IDOR vulnerability, if you can modify/get user details to take over their account. Enumerate all user's details.

• We can try changing "role" parameter to access admin privileges and perform actions.

IDOR prevention

Access controls

• Use Object-level access control

• Use role-base access control

Objects referencing

• Using salted hashes or UUIDs.

• e.g., UUID v4