In these modern days every company is facing a data breach, but have you ever wondered how these data breaches happen? How does hackers access sensitive data?

I used to imagine hackers with hoodies and night googles breaking into buildings at night and collecting data from their server but actually it is not the case. Today we are going to talk about a simple yet extremely impactful vulnerability that is often used by attackers to gain access to sensitive data of the customer. Yes! you guessed it correct, it is IDOR 

What is IDOR?

IDOR stands for Insecure Direct Object Reference and keeping the fact in mind that it has a long and difficult name, IDOR is a very easy vulnerability in which anyone can get their hands on. Essentially, just remember this: IDOR occurs when the access control is missing or not implemented properly.

Let’s understand the vulnerability with an example! Let’s say pass.com is a social media site that allows you to chat with others. And when you signed up, you noticed that your user ID on the website which is 0001. This website has a URL that allows you access all the conversation between you and your friends and is located at the URL: https://pass.com/messages. When you click on the “View Conversation” button located on the upper most corner of the page, you get redirected to:

https://pass.com/messages?user_id=0001

When you visit the above URL, you can see all the messages between you and your friend. Now, ever thought of changing the user id number in the above URL, Let’s try to do it.

https://pass.com/messages?user_id=0002

Now after changing the URL you could see all the messages of another user (whose user id is=0002) and all of his confidential information. Then you successfully found an IDOR vulnerability. But how does this happen? lets understand it with the help of an image.

The reason you were able to see the confidential information and messages of the particular user whose user id is 0002 is because there were no identity checks performed by the server before returning the private info of that particular user. The server was not verifying whether the user id 0002 belongs to your or any other user before returning the confidential information which was asked by the server.

IDORs generally occur when access control is misconfigured by the server, and when the references to data objects (like a file or a database entry) are predictable. In this case, it was very easy to interfere the values of the parameter of user 0001 and user 0002

https://pass.com/messages?user_id=0001

https://pass.com/messages?user_id=0002

What can we do to improve it?

The website can use unique and unpredictable key which makes it very difficult for the attacker to guess it.

https://pass.com/messages?user_key=6MT9EalV9F7r9pns0mK1eDAEW

Then, the website would have better security and would be very difficult for the attacker to predict the key. But most of the sites implement these insecure, direct, object, reference.

These kinds of “Direct Object References” open doors for IDOR vulnerability, which would allow anyone to grab the information which is not associated with his identity. 

IMPACT OF IDOR:

As you can in all likelihood imagine, IDORs can turn out to be exceptionally unfortunate for associations. For the present circumstance, think of all the consequences that pass.com will face when it’s users will come to know that privacy has been compromised.

The vulnerability could be exploited in a more aggressive way and could harm the company even more if the attacker writes a script to steal all the user IDs and scrape all of the data automatically. Let’s imagine that this vulnerability is on a shopping site then the attacker has the capability to steal millions of bank account details followed by their credit card numbers and the addresses. If the vulnerability could be found on any banking site, then the attacker has the capability to leak everyone’s credit card information. This is how dangerous the attack can be. They are not just limited to gaining access to others information but it can also be used to edit data of another user, let’s imagine if you can change your own password by going to the above link 

https://pass.com/change_password?user_id=0001

And you can change the password of user number 0002 if you visit:

https://pass.com/change_password?user_id=0002

This ability allows you to assume control over the record of any individual on the stage through modifying their passwords aside from their assent! IDORs on basic functionalities, for example, secret key reset, secret word change, and record mending are fundamental weaknesses that comprise the whole web application.

HOW TO FIND IDORS?

In Mozilla Firefox there is an option known as secret tab to test the IDOR vulnerability. So, when we use the normal tab as a normal user, we can go to the secret tab as an attacker. This will make sure that you don’t logout of the session.

You can also make use of Burp Suite’s for this activity; you can use the HTTP History feature where you can find all the requests and the response which took place between your device and the web server. Also, there is a scope feature in burp suite which used to save some time because in the scope feature, we can add our testing item in scope and burp suite will show the relevant data for your testing scope.

Let’s take the previous site as an example: The company “pass” that we are testing we can give the scope as “pass.com” on the scope section. In the above case, you can add this website to scope by right-clicking on the request and editing the added scope value according to the given scope. Then we can go to the HTTP History section and click on “show only in-scope items”.

CHALLENGES FACED BY PENTESTERS

IDORs are so tough to forestall because computerized vulnerability scanners are highly awful at finding them. So, the fine way is by manually studying the supply code and test if all the direct object are covered by get right of entry to control.

Manual giving a shot is furthermore a fine approach to looking at for IDOR. While information testing, you need to make two specific payments and check whether you can get to the record facts of the most important record utilising the subsequent file.

While testing, be careful that IDORs can show up in URL parameters, form field parameters, file paths, headers, and cookies. Catch every one of the requests going between your web client and the web server. Assess every one of these requests cautiously. Go by means of each request and consistently test the parameters that incorporate numbers, usernames or IDs.