IDOR Vulnerabilities in Web Applications (Insecure Direct Object Reference) Chances are they’re alive and well in your web applications. The bad news is – if you’re foregoing source code reviews by a security professional and relying on automated scanning tools to detect them, you’re out of luck; you won’t find them. But hackers do. And they can easily exploit them. And we see from the recent Verizon data breach investigation reports that they are.
The good news is with greater awareness and diligence IDOR vulnerabilities can be found and resolved. Today Kyle and I are talking with our good friend Chris Centore: Chris is an OSCP, and an expert penetration tester. He explains what IDOR vulnerabilities are and why automated scanning tools can’t detect them. And he gives an on-screen demonstration of a real IDOR vulnerability and shows just how easy it is to exploit them. If data security is important to you and what you do, you don’t want to miss the next 10 minutes.
The Verizon Data Breach Investigation Report (DBIR)
The Verizon data breach investigation report for 2020 says 45% of all breaches are related to hacking. And 90% of all hacking is through web applications. Today we are going to talk about insecure direct object references or IDOR. IDOR is one of the major vulnerabilities in a web application. It is in the OWASP top 10 vulnerabilities since 2007. Today we have the honor to talk with Chris Centore. Chris is an expert in this area.
What is Insecure Direct Object Referencing or IDOR?
Chris Centore, OSCP:
IDOR is the ability to access data directly from a data source using user supplied input. What this means for web applications is the ability to make requests to API’s for data that should be restricted, like data of another application user.
How often do you see IDOR Vulnerabilities in the wild?
[It’s a] good question. We’re definitely seeing them in the assessments that I do on web applications. There’s a big increase in these types of vulnerabilities.Do you see this problem in smaller or larger companies?
I think the issue affects both small and large companies because with smaller companies their applications will be less complex, but they often lack the security resources in-house to find these types of vulnerability. With larger organizations even though they may have the security resources on hand, the increased size or complexity of their applications make it difficult to find all the vulnerable areas.
Why we are seeing a rise in this kind of vulnerability?
Well as Kyle mentioned this vulnerability has existed for a long time, however its resurgence, I think, is largely due to a shift in how the web applications function. In the past the application servers were responsible for processing and displaying data as well as providing application functionality. But now more and more applications are simply just returning structured data through API endpoints and then letting the client do all the heavy lifting, usually with JavaScript. So the challenge for developers is ensuring each of these API endpoints are properly secured
IDOR Vulnerabilities aren’t found with automated scanning tools!
Another thing to note is that this type of vulnerability is rarely found with automated vulnerability scanning tools because those tools don’t know what types of data you should be able to access. This means that if organizations are only using an automated security check prior to releasing applications into production, this vulnerability will most likely still be present.
What causes IDOR vulnerabilities to occur within web applications?
Oh that’s a good question. I think there are two main reasons this vulnerability occurs:
- The first exists within the applications mechanism for verifying access. Often access to resources require authentication in the form of either an HTTP request header or a cookie. And the application has to verify two things:
- One, the user’s credentials are valid, and
- Two, they grant the user permission to access the requested resource. So if an error occurs in either of those checks a IDOR vulnerability will be present.
Chris presents an on-screen example of an IDOR Vulnerability
Let me show you a simple demonstration that helps explain. In this simple application demo, we show how an IDOR vulnerability might arise. For this demonstration we have an application where the URL for an API endpoint is API users, and then the idea of the user, presumably. When we make this request in our browser we get a response with the application users data ID: “user 1”, so that’s confirmed.
The users name is Bob and then we have his password and email address. The IDOR vulnerability arises when the application server fails to properly validate the session token when accessing data, other than the user’s own data. So for instance, if we were to increment this ID – let’s say – and make a request but leaving our session ID the same, which should be tied to our user Bob, when we make the request, the response returns data for an entirely different user. This is the basis for the IDOR vulnerability.
As you can see from the demo the vulnerability is not hard to exploit but it can still be pretty serious.
2. The second reason IDOR is occurring has to do with the increase in application complexity.
Chris, how do web applications and the API’s complexity contribute IDOR problems?
Because web applications are becoming increasingly complex, for example, they’re using more and more API endpoints. We’re usually seeing that while some of these endpoints are properly secured, there are often a few that – some applications can have over a hundred endpoints – and I think with so
Many of them, it’s just easy for developers to miss a few of them.
What are the main risks regarding IDOR Chris?
The main risk occurs when an attacker is able to access another users data within a multi-tenant application. Multi-tenant applications are those that serve multiple unrelated users like Facebook or Gmail, depending on the kind of data processed by the application. And whether the ID or vulnerability provides read/write or delete access, so that can lead to a pretty serious breach for an organization. Another type of risk exists if the ID or vulnerability enables an attacker to access data with a higher
privilege context, for instance, administrative functions or administrative data. And this is typically referred to as privilege escalation. Either way both are usually very serious issues.
What can companies do to mitigate these issues?
Well the short answer is to ensure that each area of the application that accepts requests for data are properly checking for both authorization and authentication of the requesting user. However to address the systemic issue, organizations should have a procedure for checking application code prior to its production release. There are numerous ways to implement this, such as SDLC that incorporates security checks during development.
Comment from Kyle Lai
That’s a good point because companies should establish secure coding practices and then teach developers how to write secure code.
Smaller companies often lack budget for SDLC
So, a lot of smaller companies have very flexible development processes [and limited financial budgets] and so a rigorous SDLC (Secure Development Life Cycle) may not fit well with the increased overhead [cost]. So to address vulnerabilities outside the development lifecycle, there are two additional options:
What other options do they have?
- A source code review by a security professional,
- Or a penetration test against an instance of the application running in either development or QA environment.
Source code reviews are tedious but thorough. This can make them more expensive. A penetration test offers an organization a view of the application through the eyes of an attacker. And sometimes even
highlight the impact more clearly. However with a penetration test they may not discover all instances of a particular vulnerability within a tested application.
How effective are the automated static analysis tools in doing the secure code review?
It’s still important to note that automated tools that check the source code or a running web application for vulnerabilities are still likely to miss the IDOR issues. This is again because the automated scanners won’t understand how your application is structured, and so, they won’t know what types of data the user should or shouldn’t have access to. So it’s still best to have the applications manually tested by a security professional.
Do you see the IDOR problem getting better or worse?
It’s a hard question to answer because I think that the places where the vulnerabilities arise will continue to grow but the awareness will also grow. So, it’s hard to know exactly; it’s hard to predict if it will continue. It’ll always be an issue, right, like SQL. SQL injection is still an issue. We’re like 20 years…. well it may be not 20 years but more like 16 years since that was a new thing, so it’ll exist for a long time.
My inclination would be that it’s probably going to become more prevalent because it is so difficult to check for with automated tools. So for instance, if it was a new vulnerability that could be checked by a signature or, if it could be analyzed through some output, then it could be baked into web applications scanners. But I don’t really see how that would be possible.
So, it will get a little bit worse for a few more years?
I think what’s going to happen is, smaller companies will try to keep up with the latest trends in development. They’ll be rolling out more and more API type applications but they won’t have
the back-end support of security to ensure that each of them are protected and secured.
In Conclusion
Well gentlemen thank you very much for your expert input on this important issue. It’s certainly relevant to we’re experiencing out in the field. And Chris and Kyle, thank you very much for your contributions today to this video. I think people will find it very helpful so thank you.
Thanks Paul and Kyle for having me I really appreciate it and it was a pleasure.
We’d enjoy hearing your feedback on today’s discussion. Please leave a comment below and click the like button and please let us know your suggestions about topics of interest you’d like us to cover in our next videos. We’re cybersecurity consultants who help clients mitigate and resolve the type of issues we discuss in these presentations. We understand business organizations operate within budgetary constraints. We help identify cyber risk based on criticality and provide solutions that are cost conscious, budget-friendly and can be phased in over time. You can contact us through our website and we hope that you will. Thank you for watching, stay safe and be well everyone. And happy 4th of July
We have related video discussion for you about Current Trends in Data Vulnerabilities:
And for additional information please see our PDF file available for download