In the previous posts, we already covered the most critical vulnerabilities like XSS and SQL Injection as well as some moderate ones like CSRF. In this post, we will see how to test for vulnerabilities like Insecure Direct Object References also known as IDOR.

So, what is IDOR actually?

IDOR was considered to be the 4th most dangerous vulnerability by OWASP Top Ten in 2013. But in the 2017 release of OWASP Top Ten of critical vulnerabilities IDOR got merged with the Missing Function Level Access Control to be at the 5th position which is Broken Access Control. Now don’t start thinking it’s less critical now. Don’t forget, it is still in the OWASP Top 10 and its exploitability impact can be very dangerous because the attacker can have various details for which he/she was unauthorized. IDOR is actually an Access Control flaw. It is a very common vulnerability in web application and its exploitability is very easy.

Insecure Direct Object References or IDOR occur when an application takes input from the user and uses it to retrieve an internal object such as a file or database key without performing sufficient authorization. In these cases, the attacker can then make changes in the references to get access to unauthorized data.

How to test for IDOR?

Cool, so you now know what IDOR is, i.e. the theory part. So let’s head to the testing part.

The first thing you should do as a tester is to make a list of all the locations where user input is used to reference object directly. Now this object can be a row from a database record or a file or any URL. Now by varying the parameter which was used to retrieve the object you can know if you can retrieve the objects of another user which will essentially mean bypassing of authorization.

Let’s see a practical example now.

Suppose there is a website for a bank "www.bankwebsite.com". Let’s say that you already have an account with the bank. You just log in with your credentials. Now, after login, you want to see all your transactions so you click on the Transactions tab. You can use a proxy software like Burpsuite to see the request for more details.

The URL will look something like this,

https://bankwebsite.com/transaction.html?uid=25671

As you can see, the transaction details are being shown with the parameter uid in the URL and the uid here means your user id or the ‘id’ which distinguishes you from all the other users who are using the same application.

Now previously we told you that for IDOR you have to check the parameters which if manipulated can lead to the retrieval of data for other user’s account which you are not unauthorized for.

As an example, in this case, you can just change the uid parameter, let’s say from 25671 to 25673.
So, now the URL looks like this,

https://bankwebsite.com/transaction.html?uid=25673

Now if the request is vulnerable to Insecure Direct Object References you will be able to see the transaction details for that user whose user id is 25673.

Now, this attack is also quite prevalent on e-commerce websites. Consider an e-commerce site is vulnerable to IDOR attack and a user can see all the payment details of another user. Now, this can lead to serious issues if we just make an automation script for getting details like the best-selling products or the number of new customers every day.This information can then be very helpful for the site’s competitor which can then bring greater offers and this can harm the company’s business. So the business impact of this vulnerability is the information it discloses.

How to prevent IDOR in web applications?

• The best-recommended measure is to provide a randomly generated id instead of just an integer in all the above cases.
  Something like this can do the trick because in this case, the attacker won’t be able to guess any other user’s id.https://samplesite.com/deleteProfilePic=x54yu8lo8t487gqw87g67r
• Also, the most important thing is to implement the access control in the first place. The user must be properly authorized for the requested information before the server provides it.

Some useful tips:

• If you are testing a particular web application for IDOR, the first thing you need to do is make two user accounts on that web application. Instead of randomly guessing the different parameters for another user, you can just see the different objects for your two user accounts and then try to retrieve the details of one user account from the other.

• IDOR attack can be anywhere where a parameter is involved. Let’s suppose there is a website and it’s giving an option to delete your uploaded picture. Now, just think what if the URL will be like:https://samplesite.com/deleteProfilePic=127Now let’s say that this request is vulnerable to IDOR attack.
  So you change the deleteProfilePic parameter to ‘128’ and it deletes some other user’s picture. It can be a huge loss for the company itself for such a violation of privacy.

So, now you know the basics of IDOR and how you to test for it. Do not get discouraged if you are trying to find IDOR and didn’t get one. Companies nowadays are doing their possible best to at least take the measures to prevent any attack from the OWASP Top 10 as it has become a security standard. The main trick for finding IDOR is to intercept the requests with a proxy like Burpsuite or ZAP and try changing the parameters to different values and see their responses.

For learning in deep about this attack, have a look at these pages from OWASP:

https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References

https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)

In any case, if you are facing difficulty testing, feel free to comment below and someone from team Enciphers will help you as soon as possible.

Till then keep learning and happy hacking..:)

‍