Using web pages, the user in most cases sends HTTP requests. They can be parameterized with values and their key. An example request, displaying a post whose id is 213, might look like the following.

https://dummy-domain.com/blog/posts?id=213

By dynamically manipulating the parameters on the page, we gain direct access to the data, and if the permission system has not been properly implemented, we are able to unauthorizedly view data that should not be available to us. Then we can talk about IDOR.

We can get the used parameters on the site in several ways. These include:

• intercepting requests with the Burpsuite tool and viewing them
• by clicking more links on the page and reviewing the URI directly
• using the ready-made scripts and tools

Finding hidden parameters using Arjun script

We mentioned above about ready-made scripts. One of them is Arjun, whose repository and documentation, we refer you to here. It is a tool for detecting hidden parameters on a specific endpoint. There is a default parameter list with almost 11,000 keywords. Moreover, the scan for it only takes about 12 seconds. An example request, using the parameters from the common.txt file and the POST method for a page with endpoint /user, looks like the following.

arjun -u https://dummy-website.com/user -w ./SecList/common.txt -m POST

Types of IDOR

With the Insecure Direct Object Reference vulnerability, we can gain access to a user's proprietary data, and in other cases it can lead to tampering with files on the server. A division into four main IDOR types is accepted, due to the possible size of the potential damage. Often these types are found to overlap with each other.

• Unnaturalized data access - by manipulating parameters, an attacker is able to access sensitive application data, such as accurate user information,
• Manipulating the internal state of the application - this involves changing the internal data of the server. An example would be XSS injection,
• Performing unauthorized operations - by manipulating parameters, we are able to perform unauthorized operations on the application. Thus, for example, we are able to gain permanent access to the account of other users,
• Direct access to server files - allows us to view and edit server files. This allows us to get information about user passwords from the database. What are the consequences of this - it does not need to be explained.

Some examples

User Rahul Varale in one of his posts describes a situation in which he obtained information about all users thanks to manipulation of the address_id parameter.

Example of the use of the IDOR error, proving that it is worth analyzing .js files, as they may contain elementary information. Ultimately, the error resulted in another user's account being taken over.

Interesting example, which only confirms that retests of the patched vulnerability should be performed several times. The bug previously found was fixed on endpoint with the GET method. However, POST was forgotten 🙂

Sources

https://www.netsparker.com/blog/web-security/insecure-direct-object-reference-vulnerabilities-idor/\
https://www.geeksforgeeks.org/insecure-direct-object-reference-idor-vulnerability/\
https://mayank-01.medium.com/an-interesting-account-takeover-3a33f42d609d\
https://rahulvarale.medium.com/idor-vulenebility-with-empty-response-still-exposing-sensitive-details-of-customers-bdce0a6a1b07\
https://infosecwriteups.com/how-i-made-it-to-google-hof-f1cec85fdb1b