WTF IS IDOR!?

One of the most crucial Vulnerabilities listed in top 10 of OWASP is Insecure Direct Object Reference Vulnerability (IDOR Vulnerability). In this article we will discuss IDOR Vulnerability. Before moving ahead, let us first discuss Authentication. Authentication means to verify the identity of a person and allow that person to access specific requests if the user is authenticated (verified). But if a user is not authenticated and can be able to view files i.e. open files in a wrong way like the Hackers/Attackers do?, it is called Broken Authentication. This article will focus on the way an attacker uses Broken Authentication Vulnerabilities that may lead to IDOR.

What is an IDOR Vulnerability?
In a web application, whenever a user generates, sends or receives a request from a server, there are some HTTP parameters such as “id”, “uid”, “pid” etc that have some unique values which the user has been assigned. An attacker can see such parameter values in cookies, headers, or wifi Packet captures. Via this, an attacker might be able to tamper these values and this tampering may lead to IDOR.

For example, let’s say that the web application displays transaction details using the following URL

https://tryhackme.com/myaccount/uid=2022

A malicious hacker could try to substitute the id parameter value “14" with other similar values, for example:

https://tryhackme.com/myaccount/uid=2021

Here we can see that the uid in the URL seems to be vulnerable and can be tampered by an attacker to break the authentication.

The “2022" transaction could be a valid transaction belonging to another user. The malicious hacker should not be authorized to see it. However, if the developer made an error, the attacker would see this transaction and hence we would have an insecure direct object reference vulnerability.

lets first se how back-end looks like.

The code abobve shows how attacker can modify “victim” to “attacker” and get victims information.

When the user tries to access one of own messages, a request went to “/uid=2021” and own message id seems to be “2022”. Likewise, when trying to access another user’s message by making a request to “/messages/16”, the message will not be accessed. When the user wanted to add another user to own message, arises a request like the one below.

POST /messages/5955/invite HTTP/1.1
Host: www.tryhackme.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: */*
X-Requested-With: XMLHttpRequest
Cookie: my_cookies
Connection: close

user=testaccount2

At first place,If you are lucky, you can see only the requests that an authorized, admin user should see in javascript files. Because of this, source code and especially javascript files should analyze well.

Also, you can search web application’s old version on “archive.org” and you may can find useful requests in old javascript files or you can search requests in search engines using dorks.

In some cases, id values aren’t unique like 1, 2, 3, 100, 1000 etc, these id values can be encoded or hashed value. If you face an encoded value, you can test the IDOR vulnerability with decoding the encoded value. If you face a hashed value, you should test whether the hash value is an accessible or predictable value. In another case, you can access hashed value in “Referrer“ header, so these scenarios can be replicated.

For example, you can’t access the another users’ objects but you can find object’s hashed id value in the object page’s source code, you can find the object’s hashed id into an in-app message from victim user (this will decrease the impact of bug). So you can create 2 test accounts as X and Y, then try to X’s hashed id value in Y’s requests in Burp History.

If we will touch another topic, some applications’ requests may scare you. For example, the SmartSheet’s request that contains more than one parameter appears to be too complex.

what you have to know is If you do not see a parameters like “id”, “user_id”, “value”, “pid”, “post_id” while creating an object, you should add it and test it yourself. You can find the parameter key name by deleting or editing any object on app.

“Authz”,

“AuthMatrix”

“Authorize”

Authentication Bypass: As the attacker can have access to millions of account with this vulnerability, it will be a type of Authentication bypass mechanism.Exposure of Confidential Information: When the attacker will have control over your account via this vulnerability, it is obvious that an attacker will be able to come across your personal information.Alteration of Data: An attacker may have privileges to access your data and alter it. By this, an attacker may have permission to make changes to your data, which may lead to manipulation of records.Account Takeover: While an attacker may have multiple access to user accounts just by changing the “UID” values, this will lead to account takeover vulnerability. When one vulnerability leads to another vulnerability(like in this case), It is known as Chaining of BUGS.

First, you should control all normal, ajax and API requests when creating an app. For example, can read-only user write anything in app? Or can non-admin user access and create API token that only created by admin user? So, for the test all of IDOR vulnerabilities, you should think like a hacker.

You can provide permission on your application for all endpoints. If your “privatesection” endpoint includes the API requests such as “/api/privatesection/admins”, “/api/privatesection/console”, “/api/privatesection/tokens”, you can block the endpoint for non-admin users.

Also, to make the attacker’s job harder and even sometimes even to prevent it, you can use hash function and use hashed values instead of normal number or string

>>follow me on twitter<<……thanks reading :)