Insecure Direct Object Reference (IDOR)

Introduction

It is the act of exploiting a misconfiguration in the way user input is handled, to access resources you wouldn't ordinarily be able to access. IDOR is a type of access control vulnerability.


Types of IDOR

1. Blind IDOR:

The type of IDOR in which the results of the exploitation cannot be seen in the server response. For example modifying other user private data without accessing it.

2. Generic IDOR:

The type of IDOR in which the results of the exploitation can be seen in the server response. For example accessing confidential data or files belonging to another user.

3. IDOR with Reference to Objects:

Used to access or modify an unauthorized object. For example accessing bank account information of other users by sending such a request →example.com/accounts?id={reference ID}

4. IDOR with Reference to Files:

Used to access an unauthorized file. For example a live chat server stores the confidential conversations in files with names as incrementing numbers and any conversation can be retrieved by just sending requests like this →example.com/1.log, example.com/2.log, example.com/3.log and so on.


In Query Components

For example, let's say we're logging into our bank account, and after correctly authenticating ourselves, we get taken to a URL like this https://example.com/bank?account_number=1234. On that page we can see all our important bank details, and a user would do whatever they needed to do and move along their way thinking nothing is wrong.

There is however a potentially huge problem here, a hacker may be able to change the account_number parameter to something else like 1235, and if the site is incorrectly configured, then he would have access to someone else's bank information.


In POST Request Variables

Examining the contents of forms on a website can sometimes reveal fields that could be vulnerable to IDOR exploitation. Take, for example, the following HTML code for a form that updates a user's password.

<form method="POST" action="/update-password">
    <input type="hidden" name"user_id" value="123">
    <div>New Password:</div>
    <div><input type="password" name="new_password"></div>
    <div><input type="submit" value="Change Password">
</form>

You can see from the second line that the user's id is being passed to the webserver in a hidden field. Changing the value of this field from 123 to another user_id may result in changing the password for another user's account.


Cookies

To stay logged into a website such as this one, cookies are used to remember your session. Usually, this will involve sending a session id which is a long string of random hard to guess text.

Sometimes though, less experienced developers may store user information in the cookie its self, such as the user's ID. Changing the value of this cookie could result in displaying another user's information. See below for an example of how this might look.

GET /user-information HTTP/1.1
Host: website.thm
Cookie: user_id=9
User-Agent: Mozilla/5.0 (Ubuntu;Linux) Firefox/94.0

Hello Jon!

Last updated