IDORs - What are they and why it's a thing?

 

 

Introduction:

Hello everyone. New vulnerabilities and exploits are being found on a daily basis. But one of the most common vulnerabilities is "us". We humans are not that great at designing something secure, especially when it comes to the Software/Web Development field. Simple misconfigurations and a general lack of secure code is rampant in today's world. One such thing is IDOR - Insecure Direct Object Reference.

 

IDORs:

I know the name sounds daunting, but it's a really simple vulnerability. It just means that a person is able to do certain things which they are not supposed to do. See? It's that simple. These IDORs are the result of poorly coded software or applications with little or no security in mind. So they are almost purely due to human error.

But what does it mean in the world of computers? It means that a person who doesn't (shouldn't) have access to an information can access, modify or delete it. In simpler terms, you can access or modify my or any other person's data without having permission to do so. This is a really bad thing. Attackers accessing something sensitive like PII (Personally Identifiable Information) of the users or the source code of the software can make irreversible damage to a company. That's why IDOR's are rewarded handsomely in bug bounty platforms. Not because they are technically difficult to find but rather, their impact is high.

 

IDOR Example:

IDORs are present everywhere. Let's look at a very simple example of an IDOR. Let's imagine we have a text chat website called "https://ourwebsite.com" and we store all the chat messages of our users as text files in our server. The text file name is a 5 digit number followed by .txt. To call the chat messages, let's imagine we are using a URL like this: "https://ourwebsite.com/assets/12345.txt".

This is a terrible thing to do without even considering IDORs since it practically tells the attacker that the chat messages are stored as text files named by 5 digits of numbers.

But let's come back to IDORs. If we don't assign proper permissions to the data and users, an attacker can simply modify the filename to retrieve a transcript created by another user and get their chat messages. All he/she has to do is to simple change the "../12345.txt" in the URL to any 5 digit number followed by ".txt. If the file exist, it will be printed. 

Yeah. Its that easy!

Wait it sounds easy to mitigate ...

The above example is a very basic one and in real life, it isn't this easy. If this website we hypothetically made up exists in the real world, the developers must have been severely underpaid.

Now you might ask what it look like in the real life. Well, it depends. IDORs are in a way like Business logic errors. They don't have a fixed structure unlike XSS or SQLI. They can be anywhere where there is any type of user identification is involved.

Now let's see another example which might be more closer to real life.

A real world example:

Let's say the developers of our hypothetical website "https://ourwebsite.com" were not underpaid this time and they did a pretty decent job of securing the site's chat messaging system. But they still are developers who don't always keep security in their mind. Let's see if they have left some holes open.

For reference, imagine this is the new webpage:(Source: Portswigger web academy "Insecure direct object references" lab)

The "View transcript" button let's you see only your latest text message with the imaginary person Hal Pline. Or is it?

Let's fire up Burpsuite (any packet interceptor like OWASPZAP will work) and listen what happens when we press the "View transcript"button.



We got a GET request which gets the text file! The response of this request gives this normal response:

This is not that dangerous in its own. But let's do something interesting. Send the above request to Burp repeater (Repeater is a powerful tool in Burp which allows you to modify requests). In the request, change the "../2.txt" to "../1.txt" and click "Send".

Request:

Response:

We got the text file of another person? Damn those developers, at first I thought they were just underpaid, now they have proven that they are just lazy. Ok, lets get to back IDORs.

It's not confined to just chat messages!

What we just saw was a simple real world example for IDORs. But it's not just messages stored in .txt files that are vulnerable. A server which identifies users with lets say an user id (not UUID, which technically is an user id, but its much harder to guess) which is easy to guess is equally vulnerable.
Let's say the website identifies users with an user id of 5 digit numbers. This user id might be used to check if the user has access to view or modify or delete a piece of data.
An attacker will create a dummy account in the website and try to access the data which he/she don't have access to. Naturally the website will tell them they don't have access. But here's where burp can help them.

They can intercept the packet and change the user id, which is a 5 digit number again and again until the user id of the account which has access to the data is obtained. Now the attacker can simply swap his/her user id in the request with the user id of the account which has access to the data to view or possible modify or delete the data. This can be achieved in lightning speed if Burp Intruder (Burp's own brute forcing tool) is used.

The above example is also just that, an example. As mentioned earlier, IDORs don't have a specific structure. So we can't just explain all of its types. You will know about the general patters of IDORs once you start looking for them.

Ways to mitigate IDORs:

There are many ways to mitigate IDORs. One of the best ways (and my favorite) to do that is to use Session cookies. The user must have a session cookie and then look at the user ID at the backend instead of just taking everything incoming. Implementing session cookies not just prevent IDORs, but also do many other things like shortening the time for an attacker during an MITM attack.

Conclusion:

IDORs are currently everywhere and they are being found and rewarded left and right in bug bounty platforms. The funny thing is the possibility of IDORs completely disappearing from the internet is close to NIL because they are basically errors caused by humans. So until robots take over the jobs of developers, it's pretty sure that IDORs will be around (By the way, robots are already taking development jobs. So if you are a software/web developer who believes machines won't be able to make more machines and your job is safe, you might be out of  your job soon. So yeah, take care. But don't worry, we all have a few more years, so until then, we will have IDORs to keep us company)



Connect with me on Linkedin!