Insecure Direct Object References (IDOR)

Steiner254

6 min readFeb 6, 2022

~ In this article we will cover:

1) Introduction

2) What are the Insecure Direct Object References (IDOR)?

3) Common types of IDOR vulnerabilities.

4) How to find IDOR injection points.

5) Interesting cases of IDOR bugs.

6) Mitigation of IDOR vulnerabilities.

7) References

8) More references to a visit!

1. Introduction

$ touch Hello Hackers :)

Hello Hackers :)

$ whoami

My name is Steiner254 (Alvin Mwambi). Beyond A Script Kiddie In A Grey Hat || Technical Writer || Penetration Tester @_techsta|| Software Developer || Bug Bounty Hunter || CTF player || Computer Science student.

>> Follow me twitter https://twitter.com/steiner254

~ Insecure Direct Object References (or IDOR) is a simple bug that packs a punch. When exploited, it can provide attackers with access to sensitive data or passwords or give them the ability to modify information. IDORs cannot be detected by tools alone. IDORs require creativity and manual security testing to identify them. While some scanners might detect activity, it takes a human eye to analyze, evaluate, and interpret.

~ If IDORs are simple, why are they so common?

2. What are the Insecure Direct Object References (IDOR)?

~ An insecure direct object reference (IDOR) is an access control vulnerability where un-validated user input can be used for unauthorized access to resources or operations. IDORs can have serious consequences for cyber-security and be hard to find yet easy to exploit. An insecure direct object reference (IDOR) is an access control vulnerability where un-validated user input can be used for unauthorized access to resources or operations.

3. Common types of IDOR vulnerabilities

~ IDOR vulnerabilities can be used to exploit filenames to download unauthorized files by changing the filename:

>> http://www.ifiles.com/download_file.php?a.txt

~ IDOR vulnerabilities can be used to change passwords of different users by hijacking their ids and accessing their accounts:

>> http://www.ifiles.com/change_password.php?id=1024

~ IDOR vulnerabilities can be used to hijack cookies of users that include their saved passwords and additional sensitive information, by merely replacing the cookie ID:

>> http://www.ifiles.com/cookieid=002891981

~ IDOR vulnerabilities can also be used to gain access to the server and display files that users could not see otherwise:

>> http://www.ifiles.com/display_file?../../../../etc/passwd

4. How to find IDOR injection points.

~ One can find many requests for IDOR vulnerability testing using all features of application. When API endpoints are not provided in IDOR vulnerability tests, .html source code or .js files are useful. These files include interesting things and ajax requests usually. IDOR vulnerability testing can be performed using presented requests in these files. This can be requests made earlier by the application, and possible future requests. If you are lucky, you can see only the requests that an authorized, admin user should see in Javascript files. Because of this, source code and especially javascript files should analyze well.

~ One can also search for web application’s old version on “archive.org” and you may can find useful requests in old javascript files or you can search requests in search engines using dorks.

~ In some cases, id values aren’t unique like 1, 2, 3, 100, 1000 etc, these id values can be encoded or hashed value. If you face an encoded value, you can test the IDOR vulnerability with decoding the encoded value. If you face a hashed value, you should test whether the hash value is an accessible or predictable value. In another case, you can access hashed value in “Referrer“ header, so these scenarios can be replicated. For example, you can’t access the another users’ objects but you can find object’s hashed id value in the object page’s source code, you can find the object’s hashed id into an in-app message from victim user (this will decrease the impact of bug). So you can create 2 test accounts as X and Y, then try to X’s hashed id value in Y’s requests in Burp History.

~ Some applications’ requests may scare you. For example, the Smart-Sheet’s request that contains more than one parameter appears to be too complex. If you want to find the inject point in this request, you can use Burp Suite’s comparer tool. You should right-click on the request and choose “Send to Comparer” option. Then you can create the same request for using another object and send to comparer. When you visit to the comparer tool and click on the “Words” button, you will be presented with a window where the changing points.

5. Interesting cases for IDOR bugs

a. Manipulate the create requests

~ Some applications create an id on client-side and then send the in create request to server. This id value can be number such as “-1”, “0” or anything. The existing id values change with the previously created objects’ id. So you can delete / edit other users’ objects using IDOR vulnerability. If you do not see a parameter like “id”, “user_id”, “value”, “pid”, “post_id” while creating an object, you should add it and test it yourself. You can find the parameter key name by deleting or editing any object on app.

b. Blind IDOR

~ In another case, you can find an IDOR vulnerability but you couldn’t realize that. For example, if you change the object’s information in application, you’ll get an email that includes the object’s information. So if you try to change another user’s information of object, you can’t access anything in HTTP response but you can access the information of object with an email. You can call it “Blind IDOR”.

c. Chaining IDOR

~ IDOR vulnerabilities can help you by triggering other vulnerabilities that cannot be exploited. If you find an unimportant IDOR vulnerability such as editing users non-public & unimportant filename and you want to raise the impact of your bug, you can use self-XSS bug. The self-XSS vulnerability that you found while the web application testing is generally out of scope and not rewarded. However, you can combine self-XSS vulnerability with another IDOR vulnerability and you can submit report as “IDOR + Stored XSS”. In this way you can achieve a vulnerability of P2 level.

d. Critical IDORs

~ IDOR vulnerability allows us to access an account at some time, rather than to edit or delete it. These critical bugs appear in fields such as password reset, password change, account recovery. So first, you should double check the link in your email and parameters in it. Then, you can capture the password reset request and examine the parameters with any proxy tool. We have seen many times the “user id” value in these requests and we could takeover to another user’s account easily. At the same time, it’s an important thing that’s account takeover by header values sent in the request. It is seen that some header values such as “X-User-ID”, “X-UID” from the test and debug environments are changed. So that the user can act like any user and was able to account takeover successfully.