Insecure Direct Object Reference

Hello guys👋👋 ,Prajit here from the BUG XS Team and Cyber Sapiens United LLP Cybersecurity and Red Team Intern, in this I am regularly given some interesting tasks, In my eighteenth task I was given to research about Insecure Direct Object Reference Vulnerability.

What is IDOR?

IDOR stands for “Insecure Direct Object Reference”. And despite the intimidating name, IDOR is actually a very simple vulnerability to understand. Essentially, just remember this: IDOR is missing access control.

Let’s say for example if an user’s id is 12345 and to only know or change your profile information, one only needs to put this id in the request, then it is an Improper Access Control, which is IDOR. So in such cases an attacker can create and capture a request if changing values from their side and in the request replace their user ids with victim’s and content of victim’s profile changes without even attacker accessing it. Hence this is one of the basic scenarios of what IDOR can do.

There can be many variables in the application such as “id”, “pid”, “uid”. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This vulnerability is called IDOR.

As you can see from the above image, a malicious attacker can get a document for any user as long as he knows the document id.

How to Find IDOR Vulnerability?

To find IDOR Vulnerability you need to first understand the application logic and flow and then try to find loopholes in that logic, also keep an eye out for different requests and if they are taking any kind of id, etc to identify a certain process uniquely.

To test this vulnerability basically you need to create two accounts (one victim and one attacker). Capture the same requests on different account and compare the difference in the request via “Comparer” tool in Burp Suite, to exactly and easily find the ids which are getting changed and then you can use “Sequencer” tool in Burp Suite to find how random that certain id is or is it predictable.

Let’s discuss some examples:

1. For example there is some chat functionality being used and to send a message you are a separate id provided now if an attacker gets that id, he can message from your side without any user interaction.
2. For example, to check out a support request created a support id is given through which the application uniquely identifies the request and shows it, now if it is numeric that is sequential, an attacker can view all the support requests just by changing the number.

And so on….

What are Different Types of IDOR?

There are many different types of IDOR some main are:

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 users’ 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.

What is the Severity of IDOR Vulnerability?

IDOR is a very interesting vulnerability and each different case had different severity based on the impact or damage it is causing.

Some of the factors it depends on is:

1. Sequential/Numeric IDs: If the IDs are guessable and sequential, the attacker doesn’t have to do any user interaction to know the exact ID, he can just guess it hence “No User Interaction” Increases the severity. On other hand there are cases where the IDs are very random to know the exact ID. There will be some user interaction, hence in such cases the severity will be reduced due to “User Interaction”.
2. Privileges Acquired by the IDOR: While exploiting this vulnerability the impact also depends on the privileges gathered like if you can only see the content or change it or delete it, hence in such cases severity increases respectively.

Some of the typical severity examples are:

P1 — Account takeover, Access very important data (such as credit card)

P2 — Change / delete another users’ public data, Access private / public important data (such as tickets, invoice, payment information)

P3 — Access / delete / change private data (limited personal info: name, adress etc.)

P4 — Access any unimportant data

How to Mitigate IDOR Vulnerabilities?

● First, you should control all normal, ajax and API requests when creating an app. For example, can a read-only user write anything in an app? Or can non-admin users access and create API tokens that are only created by admin users? So, to test all of the IDOR vulnerabilities, you should think like a hacker.

● You can provide permission on your application for all endpoints. If your “privatesection” endpoint includes the API requests such as “/api/privatesection/admins”, “/api/privatesection/console”, “/api/privatesection/tokens”, you can block the endpoint for non-admin users.

● Also, to make the attacker’s job harder and sometimes even to prevent it, you can use hash function and use hashed values instead of normal numbers or strings.

This is all for today’s writeup.

Thanks For Reading 😊

Profile Links:

Twitter: https://twitter.com/SAPT01

LinkedIn: https://www.linkedin.com/in/prajit-sindhkar-3563b71a6/

Instagram: https://instagram.com/prajit_01?utm_medium=copy_link

BUG XS Official Website: https://www.bugxs.co/