Insecure Direct Object Reference allows attackers to manipulate references to gain access to unauthorized data. A proof of concept video follows this article. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series. OWASP Top 10 2017 was released in November 2017, bringing some changes to the list from 2013. We are working on updating our content, but in the meantime, please take a look at our article about OWASP Top 10 2017.
Description
The fourth one on the list is Insecure Direct Object Reference, also called IDOR. It refers to when a reference to an internal implementation object, such as a file or database key, is exposed to users without any other access control. In such cases, the attacker can manipulate those references to get access to unauthorized data.
Prevalence
There are no good numbers to base the estimation on and OWASP’s formulation on the subject is also very vague. However, by looking at well-known events as well as public bug bounty-reports it can be confirmed that it is a very common vulnerability. This is also what we have discovered during our own security research.
Potential impact of Insecure Direct Object Reference
It is impossible to say what the potential impact of IDOR is, as it varies alot depending on what kind of data or file the attacker may get hold of. It could be anything from innocent information to bank statements, and much more.
Exploitability
Due to it being so easy for an attacker to exploit, IDOR is very likely to be abused. This of course varies as well, as it may not always be obvious how to enumerate the links for the files.
Well-known events
Back in 2010 when iPad was the coolest gadget for early adopters, AT&T suffered by an Insecure Direct Object Reference that exposed the details of at least over 100.000 owners. It exposed the email address of the owners, as well as the ICC-IDs (the ID of the SIM-card). As Apple provided the data to AT&T, they often receive the blame for this vulnerability.
By sending a request to AT&T together with an ICC-ID, the server would respond with the corresponding email address. As the ICC-IDs can be enumerated by looking at just a few IDs, this attack could be fully automatised allowing a considerable data leak.
How to discover Insecure Direct Object Reference
Code analysis is suitable for this kind of vulnerability. Every place that presents restricted data needs to be investigated, to make sure that there are checks in place ensuring that the user is authorized for the requested information.
This can of course be automated to some extent without access to the source code of the site, but having it is a great advantage. With the source in hand, a vulnerability like this is often quite easy to discover.
How Detectify can help
We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable »
Example of vulnerable application
When a user accesses the dashboard on the user’s bank’s website, the user gets redirected to the following url:
https://bank/balance?acc=123
In this case, 123 is the ID of the user’s account, and the user will therefore see that balance. If the user wanted to abuse this, it would be possible to just change the URL-parameter to someone else’s ID and instead get access to that ID’s account.
Remediation
The only real solution to this issue is to implement an access control. The user needs to be authorized for the requested information before the server provides it.
It is also often recommended to use something less obvious that is harder to enumerate as a reference. Eg., a random string instead of an incrementing integer. This can be a good idea for multiple reasons, but should absolutely not be trusted as the only prevention against such an attack.
IDOR Proof of Concept video:
Read more
OWASP:
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)
Interesting public bug bounty-reports:
https://hackerone.com/reports/42587
https://hackerone.com/reports/53858
Other:
https://www.troyhunt.com/owasp-top-10-for-net-developers-part-4/