Why IDOR Works on Some Websites and Not on Others ?

This article was originally published on Hacker's Brain. Read the original version here: https://hackersbrain.com/why-idor-works-on-some-websites-and-not-others/

Understanding IDOR Vulnerabilities

First of all, let's quickly recap what an IDOR vulnerability is. You are on a website and in the URL you see the parameter ?id=5. The current page is a Dashboard, and if you change the ID to something like ?id=7, you will access the dashboard of user 7 even though you are user number 5. However, you try the exact same thing on another website and... it doesn't work!

The obvious question then becomes: why does changing the ID work on some websites but not on others? That's exactly the question we're going to answer in this article.

Client-Side Control vs Server-Side Responsibility

As you now know, the ID parameter is used to identify the user, but what we tend to forget is that when the parameter is present in the URL, it is present in your browser (client-side), so you can always modify this parameter because you naturally control the client side.

But that's not where the problem is.

Let's think about it for a second… You can absolutely walk into a hotel and ask for room 401 (which you don't own), but the receptionist will simply tell you no, and nothing else will happen. This example may sound a little silly, but when you think about the details, you realize it actually hides quite a few things.

For example, the nuance of "you are allowed to ask for a room that isn't yours, but nothing will happen." Not to mention that the security here relies on the receptionist. If they are lazy or naive, they could very well think, "Oh, this is probably the guest staying in room 401, I trust them," and give you access.

The Key Factor: Verification

As we have just seen through this example, the possibility to make the request is always there, but the possibility of having your request refused is exactly the element that determines whether an IDOR on the ID is possible or not.

Now that we better understand why this happens, let's look at the technical side.

The Vulnerable Implementation

First, let's look at the equivalent of our naive or lazy receptionist in server-side code:

$user = getUser($_GET['id']);

$user = getUser($_GET['id']);

The idea behind this line of code is simply to say, "The server retrieves the value of the id parameter, then uses this value to retrieve the corresponding user's information."

When you read it carefully, you can spot the mistake. The code accepts the request without asking any questions. Just like our naive receptionist, it takes whatever the user provides and never questions whether the request is legitimate or trustworthy.

In short, this line of code takes the information without ever verifying it, which allows an IDOR on the ID.

The Secure Implementation

Now let's look at the professional receptionist, the one who does their job properly and refuses your request if you have no access to room 401.

In terms of code, it is a little more complete, as you can see here:

$user = getUser($_GET['id']);

if ($user->owner != $_SESSION['user_id']) {
    die("Access denied");
}

$user = getUser($_GET['id']);

if ($user->owner != $_SESSION['user_id']) {
    die("Access denied");
}

You'll notice that the first line is exactly the same, and as mentioned earlier, the parameter has to take a value in every case. It is a functional tool, so it has to keep its role.

However, what changes is the verification code that follows, which translated into plain English means:

"The server retrieves the user corresponding to the identifier provided in the URL (first line). It then checks that this user actually belongs to the person who is currently logged in. If not, it denies access."

This is exactly what our professional receptionist was doing, but in code.

Key Takeaways

You now know why an IDOR on the ID is possible on some websites and not on others. Note that the ID could just as easily have been another parameter, such as one used to display a product or search for something with a search bar.

What you should remember is that the principle remains the same, and the code is simply a little different. I wanted to focus on one specific case so I wouldn't have to be too general, and therefore less understandable.

Of course, this leads to many other questions and topics, such as the absence of parameters in the URL and the use of UUIDs instead of IDs for better security, as well as many other questions.

By the way, if you have any, feel free to leave them in the comments section. I'll be happy to write about the most interesting ones.

Learn More

If you want to learn more about vulnerabilities, and especially how to practice them, don't hesitate to check out our courses.

Happy hacking — Hacker's Brain