One of the most serious vulnerabilities that affects web applications, APIs, and microservices are the Insecure Direct Object References (IDOR). It is a design flaw characterized by allowing uncontrolled access to sensitive data without proper authorization.
Some recent examples of Insecure Direct Object References breaches are the USPS API bug that exposed 60 million records, and the Steam breach that leaked access to video game activation keys. Just a few days ago, Krebs on Security disclosed another major incident, this time at First American, a real estate financial institution that exposed some staggering 885 million property title records going as back far in time as 2003.
The combination of easy exploitability, prevalence, and the impossibility of detecting the vulnerability by traditional security tools is what makes this issue so dangerous, as demonstrated by the examples above.
What are Insecure Direct Object References
IDOR can be generalized as a subtype of broken access control. In the 2013 edition of the OWASP Top 10 it was represented by the A4 risk family, but in the 2017 edition it is part of the larger Broken Access Control family of risks (2017:A2).
In particular, a system is vulnerable to Insecure Direct Object References when the application is not performing the necessary authorization steps before serving a piece of data requested by a client. Typically, after logging into the system as a legitimate user, the attacker iterates through “identification” codes, and looks for data belonging to a different user.
Curiously, IDOR is one of the easiest flaws to understand and to exploit, compared, for instance, to Insecure Deserialization attacks.
Some examples of Insecure Direct Object References attacks
The three categories below share the same design flaw as the root cause, but then take different shapes depending on the nature of affected component:
1. URL tampering
In a URL tampering IDOR attack, a URL is modified client-side by changing parameters in the HTTP request. Contrary to popular belief, any HTTP verb (including GET, POST, and all others) is potentially vulnerable to URL tampering if the IDOR vulnerability is present.
2. Body manipulations
A hidden field tampering attack occurs when the attacker modifies locally the value of a hidden form field. These hidden fields are typically used to store object identifiers and are a major source of IDOR vulnerabilities. Similar to the hidden field type, in a combo box tampering attack, the attacker introduces or modifies values in the available options of an HTML combo box control. Tampering of other HTML artifacts such as checkboxes, radio buttons, and form fields would fall within this category as well.
3. JSON IDs manipulation
APIs and microservices that work with structured data format such as JSON and do not include traditional HTML forms are also potentially vulnerable to IDOR flaws, especially if they rely on some form of stateful session architecture to authenticate the requests.
Some APIs rely on URL parameters (“/api/users/717”) or on query params (“/download_file?id=111”). Other APIs consume body params or HTTP HEADERS (“user-id:717”).
Insecure Direct Object References Examples
This video describes some of the types of IDOR described in the previous point:
Why IDOR is so dangerous
As we mentioned above, Insecure Direct Object References are one of the most serious security issues. Let’s take a look at the main reasons why:
1. Insecure Direct Object References can not be detected by tools
First of all, IDOR is classified as a design flaw (business logic flaw) and cannot be detected by traditional Application Security Testing (AST) tools. It can only be detected by manual penetration testing. As a result, unless the pentester actively tests every parameter in every request endpoint in every app, IDOR vulnerabilities can slip through.
Certain AppSec techniques such as request fuzzers help, but they must always be supervised by a test engineer to interpret the results and identify the vulnerability.
2. Reliance on manual validation
Mitigation of IDOR requires proper authorization for each and every endpoint of your application. At the same time, the solutions to apply in this level, such as instance level security (see for example Spring Security Domain Object Security (ACLs)) are very difficult to apply and would cause performance issues in many cases.
Relying on people means that sooner or later vulnerabilities will slip through the cracks.
The adoption of agile methodologies (DevOps) that feature automated deployments and continuous delivery (CI/CD) has reduced and sometimes even removed the lead time available to audit and correct risks such as IDOR.
3. IDOR is a high-value vulnerability
Another dangerous factor is that once an IDOR vulnerability is discovered and exploited, the scale of breach is only limited by the size of the underlying data. Just by iterating on the affected identifier, the attacker can retrieve the data associated to any of these identifiers.
4. Easy to exploit
A malicious user can easily cycle through large variations of identifiers once an IDOR vulnerability has been found. Insecure Direct Object References vulnerability is one of the easiest to exploit, and a simple web browser is enough to find them, and to exploit them.
Hdiv automatically prevents IDOR
Now for some good news, we are eager to point out that Hdiv Protection, our RASP product, prevents IDOR vulnerabilities from being exploited.
In fact, automated protection against these attacks is a feature unique to Hdiv. This protection, based on RASP technology, performs an automatic runtime enforcement of the application contract.
This enforcement is based on positive security models, in other words, whitelists. An alternative model that some WAFs use, based on learning processes is well known to cause delays to learn the application every time something changes, and to throw a large amount of false positives. Learning processes are not a complete solution to this problem.
Security by design
Hdiv’s approach is based on offering security by design. Our technology provides extensions that only need to be configured once for the entire application, API, or microservice, so developers do not need to perform manual access control validations at each endpoint. Software architects love this security approach because it allows to mandate a consistent authorization approach, without depending on people.
Security by design also means that all communication between client and server is validated and protected against malicious modifications. This includes automatic protection from URL tampering, parameter tampering and all other IDOR types described above.
As a result, the entire application is protected at once, with no cracks or mistakes derived from the need to perform manual validations to ensure proper authorization.
On top of IDOR protection, which we classify as a business logic flaw and/or design flaw, Hdiv RASP protects from all traditional security bugs such as SQL injection, XSS, Insecure Deserialization, XXE and other important families of application risks. Since Runtime Application Self Protection technology is not based on rules or pattern-matching, Hdiv Protection has a near zero rate of false positives and very efficient performance. We call this approach Agile Protection.
We would be happy to demonstrate Hdiv Protection and share additional details of our technology. Drop a line to daniel at hdivsecurity.com