Insecure Direct Object Reference (IDOR).

What is IDOR ?

IDOR stands for Insecure Direct Object Reference and it is a vulnerability in which an attacker can access sensitive information by making unauthorized references.

For example, an user would retrieve his personal and confidential data by sending a request to the following URL:

https://example.com/account.php?id=24

The request collects the user ID from the URL parameter and then displays the information. But what happens when the user with ID of 24 sends the next request?

https://example.com/account.php?id=11

If the data belonging to the user with ID of 11 is returned then it is an IDOR issue. A vulnerability like this one can occur when there is a bad/weak access control implementation or there is not at all.

Types of IDORs

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.

How to test for IDORs ?

The first rule in testing for an IDOR vulnerability is to catch all the requests your browser sends to the web server. Many times you will find those type of issues in URL parameters values, headers values or cookies. You will likely find encoded or hashed values and you have to decode them. For example the following link: https://example.com/profiles.php?id=e4da3b7fbbce2345d7772b0674a318d5 The “id” URL parameter value can be easily cracked using a hash decode tool (MD5 hashed). Also, a common place where an IDOR can occur is in the API requests, so be sure that you analyze the web application, gather all the API requests that are being sent and tamper with the requested values.

Where to look out for IDOR

1:)

Find ID’s parameters: In today’s scenario, most web applications are using UUID parameters. That may contain some encoded value. Don’t get disheartened and look out for the ways of decryption if you can.

2:)

Find API’s ; They are potential for IDOR.

3;)

Find hierarchies ;By that I mean there is the certain scope that contains different roles, such as admin, user, manager, distributor, etc. They also give us a good hint to look for IDOR’s.

4;)

Find CRUD Functionality ; By that I mean there are certain applications that has Create, Read, Update, Delete functionality, & for different users they may have different roles associated with it. Try to manipulate every option.

5:)

Find Forums ; Do not forget to explore every option available to you. Rather than just looking out for creation, deletion, modification etc. Do lookout for options such as invites, chatrooms, bots functionality, sharing buttons etc.

6:)

Find whether PUT Method enabled?

If yes, then do check-out to pollute the parameter. And how exactly you can do it? Do check it out HTTP PARAMETER POLLUTION article link

https://www.acunetix.com/blog/whitepaper-http-parameter-pollution/

If you like this content or article than share it with your friends to help or find it and learn it !

Feel free to leave a comment below ;

If you have any queries regarding this ,than you can ask me at this given link ;

https://www.facebook.com/manis.neupane.33

Till next writeup bye bye have a good day !

Thank you 💞🇳🇵

©Maniesh Neupane.