What is Insecure Direct Object Reference ( IDOR ) ?

Content for everyone ( pentesters/developers/non-IT )

Before we start, let’s remember :

What is a security vulnerability (In short) ?

A vulnerability ( Also called "BUG" ) is a weakness in an IT system that can be exploited by an attacker to deliver a successful attack. They can occur through flaws, features or programmers/developers errors, and attackers will look to exploit any of them, often combining one or more, to achieve their end goal .

In this article, we will talk about one of these vulnerabilities that, up to this day is still considered as one of the most dangerous ones classified in The TOP 10 owasp called IDOR, and we will describe some common vulnerabilities.

IDOR , which stands for "Insecure direct object references" , is a type of access control.

What is an Access control :

Access control enforces policy such that users can not act outside of their intended permissions. This means that each user has his own permissions. Authorization ( Access control ) is the application of constraints on who (or what) can perform attempted actions or access resources that they have requested. In the context of web applications, access control is dependent on authentication and session management, this means that users can not access unauthorized resources for example ( read, edit, delete ), because the Authorization application checks the users permissions and prevents them from accessing to unauthorized resources .

A small example of how an Access control application works:

Every client, who will request a service from the server the RBAC aplication (Role-based access control), will check permissions of the client.

User B cannot access to user A information cause the Authorization aplication has blocked User B from accessing to User "A" information ( User B has no permissions ).

After knowing how the access control application works, What if an attacker breaks access controls ?

User B can access to User A information.

This leads to a common and often dangerous security vulnerability because the access controls is a complex and dynamic problem that applies business, Missing or Breaking into Authorizations application leads to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits .

Through Insecure direct object references vulnerability, attackers can break access controls and access to unauthorized users’ information.

What is an object reference ?

Object references is information on how to find a particular object. The object is a chunk of main Database. A reference to the object is a way to get to that chunk.

For example : sally = 79 , Which means Sally has been stored in DB as ID=97

Let’s dive deeper into insecure direct object references

Description

IDOR are a type of access control vulnerabilities, that arises when an application uses user-supplied input to access objects directly. The term IDOR was popularized by its appearance in the OWASP 2007 Top Ten. However, it is just one example of many access control implementation mistakes that can lead to access controls being circumvented. IDOR vulnerabilities are most commonly associated with horizontal privilege escalation, but they can also arise in relation to vertical privilege escalation.

Simple example for IDOR.

IDOR examples

There are many examples of access control vulnerabilities where user-controlled parameter values are used to access resources or functions directly.

Recently, we see that most companies are affected by IDOR vulnerabilities even the big ones such as google, apple, microsoft, yahoo … , because it is so complicated and complex, which makes it controversial.

Example For : IDOR vulnerability with direct reference to database objects

let’s go back to my example of " object references " .

Let us say you register on a Shop-website and when you fill your information : address , Email , phone … , you will be redirected to a page displaying all of your information for reviewing : edit , delete … .You will see a link in the browser bar like this:

shop.shellmates.xyz/user/details?id=360300

The ID "360300" is an object reference that is stored in the DB once when the account is created , it means that your-account == 360300 like the example of Sally == 79

what if you try to change that ID? You will be able to access other user-details. This confirms that there is an "Insecure Direct Object References" vulnerability.

shop.shellmates.xyz/user/profile?id=360300 ( YourAccount)

shop.shellmates.xyz/user/profile?id=360301 ( VictimeAccount)

How can we dump victim account Information? We already know that there is an "IDOR" vulnerability. We would like to exploit a specific victim.

shop.shellmates.xyz/user/details?id=360301 ( VictimeAccount-ID )

Now, you can read, edit and delete the information (email ,phone, address ) of all registered users by simply changing the ID number in the URL. The problem remains when you make a request to the server, the authorization application does not check user permissions, which means that there is a broken access control.

It Looks like this

Example For : IDOR vulnerability with direct reference to static files

When sensitive resources are located in /static/ files on the server-side file system. For example, a website might create a transaction.json file when you delete all of your transactions, this is the reason behind the fact that if you want to retrieve it, you can download a file. The link looks like:

shop.shellmates.xyz/static/transaction/1123.json

In this situation, an attacker can simply modify the filename to retrieve a transcript created by another user and potentially obtain user credentials and other sensitive data.

Attack example

Example For : IDOR vulnerability with Critical impact ( real-world )

As it has been mentionned earlier, IDOR vulnerabilities have a very sensitive impact, which makes it dangerous and easy to exploit !

One of the Bug-hunters found an easy IDOR Vulnerability " I just wanted to show how easy and dangerous it is"

I D O R to Account Takeover

The hunter started testing password reset functionality and he found this path "site.xyz/home/reset/user_id/reg" endpoint is used to change the user’s password. He tried to modify the user_id to other user’s id and BOOM !! password changed sccuessfully.

Through this IDOR vulnerability, he can reset any user’s account just by knowing the user ID. It is scary, isn’t it? Of course, the researcher reported it to the organization and they fixed the issue immediately .

These files can be accessed without the custody of the authorization like " database, user details, files, etc." It will happen when there is a broken or missing in the application of authorization . Like we mentioned previously, if the web application was directly accessing the user’s input to catch the user’s details irrespective of the explicit authorization checks, it means the web application is vulnerable to IDOR.

Conclusion

The good news is that there are foolproof way to prevent IDOR vulnerabilities. Options businesses can use to fix insecure direct object references.

The most foolproof way to prevent IDOR vulnerabilities and attacks is to perform access validation. If an attacker tries to tamper with an application or database by modifying the given reference, the system should be able to shut down the request, verifying that the user does not have the proper credentials.

In particular, web applications should rely on server-side access control rather than client-side so that adversaries cannot tamper with it. The application should perform checks at multiple levels, including the data or object, to ensure no holes in the process.