IDORs are common, potentially catastrophic vulnerabilities that result from compromised access control in web applications.
IDOR bugs allow an attacker to maliciously interact with a web application by manipulating a “direct object reference', such as a database key, query parameter, or file name.
As we learn more in this article, we will answer basic questions such as: “What is IDOR?”, “How do I find an IDOR vulnerability?” and “What can I do to protect myself from an IDOR vulnerability?”.
How an IDOR vulnerability works
To better understand how an attacker can exploit an IDOR vulnerability, let's take a look at a real-life example. A student at a university was able to access other students' files simply by changing part of the address in his browser.
He logged into the account and noticed that the app was using the code as an identifier to retrieve his course schedule, grades and other personal information. The URL looked something like this:
https://stateuniversity.example/GetStudentRecords?ID=00123456789
But what if he simply replaced the “ID=00123456789” part of the URL with another student's ID? He tried it and the system showed him the records of the other student.
Repeating this process revealed that it was fairly simple to pull the records of any university student or employee, as long as he knew (or could guess) the student's or employee's ID. Given the sensitive data being exposed, he immediately reported the vulnerability to the university.
First, the application apparently did not include authorization checks to see if someone should have access to the files they are requesting ("ifsafes” reference).
Second, the university designed its application by basing the search of records from the database solely on the student/employee identifier (“direct object reference”).
Finally, identifiers are listed in the address bar in an easily recognizable format, making handling them simple even for a cyber novicebetter safety.
Four common IDOR types
Nowadays, identifiers are more often found in headers or APIs than in a user's address bar. However, the dynamic nature of most websites means that identifiers and parameters are still heavily used in one form or another. Identifiers may include:
- Database keys
- Query parameters
- User or session IDs
- Filenames
How to spot IDOR vulnerabilities
IDOR vulnerabilities are often simple to exploit, but can be difficult for developers to detect. Tools and techniques such as code analysis and automated scanning are not as good at debugging IDOR as many other common security issues, which means that the localization of these vulnerabilities may require manual security testing.
Some ways to identify vulnerabilities include:
- Run basic tests using the built-in development tools in a web browser
- Using a tool such as Burp Suite or Open Web Application Security Project Zed Attack Proxy (OWASP ZAP) to increase the efficiency of manual testing.
- Participation in a vulnerability disclosure program
- Hire an external penetration testing company to review critical web applications
Four types of IDOR attacks
Conceptually, most attacks exploiting IDOR work in a similar way, but there are subtle nuances in which the IDOR is exposed and/or manipulated by hackers:
1. URL tampering
URL spoofing is the simplest way to exploit an IDOR vulnerability and often requires little or no technical expertise. In this type of attack, we can simply change the value of a parameter in the address bar of our browser.
In our college example, it changed the student's ID to that of other students, faculty, and staff at the university. Tools can also be used to modify the HTTP request, but the end result is the same: the server grants some kind of improper access to an attacker.
And if you have the advantage of knowing some of these IDs in advance then things are extremely simple. A real attacker would probably spend time enumerating different values and trying to discern a predictable pattern.
Below: A simple URL tampering attack can consist of changing a single identifier parameter in an address bar.
2. Body manipulation
Body manipulation is very similar to URL tampering, except that the attacker modifies one or more values in the body of a form instead of the URL. This might mean changing the values of radio buttons, check boxes, or other form elements. It may also be possible to change the form's hidden values.
Perhaps a contact has a hidden form value that passes the user ID for the currently connected account. If we can change this hidden value before submitting the form, we can make our request appear to come from a different user.
3. Cookies or JSON ID manipulation
Cookies and JavaScript Object Notation (JSON) are both widely used behind the scenes to store and exchange data between the client and server, helping to make web pages more dynamic.
When we connect to a website, for example, the server may store a user or session ID value inside a cookie or JSON object. If the application contains an IDOR vulnerability, an attacker could change these values.
4. Path traversal
Path traversal, also called directory traversal, is a unique type of IDOR vulnerability that an attacker exploits to access or manipulate files or folders on the server running the web application.
This is a level deeper than other types of IDOR attacks because it allows direct access to file system resources instead of database records. Path traversal can allow an attacker to access configuration files, discover user credentials, or even obtain a fully functional shell on the target.
How an IDOR vulnerability affects data
IDOR vulnerabilities may be simple to exploit, but the effects of this type of attack are potentially devastating. Listed below are just a few ways an IDOR can affect you confidentiality, The integrity and availability of your organization's data:
- Confidentiality – As we saw in the university example, a successful IDOR attack gives the attacker access to something they shouldn't be able to see. This could be anything from a discount code for frequent shoppers to a digital one store up to sensitive personal health information or trade secrets.
- Integrity – In some cases, an attacker may be able to use an IDOR vulnerability to modify data. Typically, these types of attacks manipulate parameters in an HTTP POST request. In 2020, a security researcher discovered an IDOR vulnerability that would allow an attacker to change the password of user accounts on US Department of Defense servers. Attackers can use similar vulnerabilities to add unauthorized data such as falsified financial information or incriminating documents to an unsuspecting user.
- Availability – IDOR can also be abused to affect resource availability. Imagine a function in a PHP application that deletes documents based on file name. Without proper authorization checks, an attacker may be able to rename files and delete documents they don't even have access to!
Four tips to prevent IDOR vulnerabilities
IDOR vulnerabilities can be prevented by avoiding direct object references, implementing user input validation, and implementing globally unique identifiers (known as GUIDs) or random identifiers. While there is no foolproof solution when it comes to preventing IDOR vulnerabilities, some of the steps below can help.
1. Implement appropriate access control and session management
OWASP, which coined the term “Insecure Direct Object Reference” (insecure direct object reference), sees IDOR as primarily an access control issue. Appropriate access controls and session management features should prevent a malicious user from being able to access or manipulate data, even when simple numeric identifiers are used. The OWASP cheat sheets on the authorization and authentication may be useful to study them.
2. Avoid direct object references
Access control issues aside, using direct object references in your application is often considered a poor coding practice. This is especially true when it comes to sensitive data, such as student/employee IDs, account numbers, etc. Indirect object references, often in the form of either reference maps or hashes, address IDOR vulnerabilities by hiding the actual identifier, which remains hidden on the server side. If hashes are used, be sure to include a strong and unique identifier, as basic hashing algorithms like MD5 are easy to crack.
3. Use GUIDs or random identifiers
In applications that use iterative or sequential identifiers or parameter values, enumerating an insecure direct object reference vulnerability is a breeze. If we notice that the user ID looks like something like 0001, for example, we can make an educated guess that there is also user 0002. Modern computing power and automation techniques make it fairly easy to then try every possible value from 0000 to 9999 until we find the user we're looking for.
Neither GUIDs nor globally unique identifiers remove the underlying vulnerability, but they make enumeration and exploitation much more difficult. An ID like f492325c-ae75-4335-a2a6-1a716b723f2a is much harder to decrypt than something less complicated.
4. Validate user input
Validating user input can help mitigate a large number of security issues, including IDOR. Enumeration of identifiers becomes much more difficult if we strictly validate user-supplied parameters for the correct length and format. Validation can take place either client-side or server-side, whichever is more appropriate.
IDOR vulnerabilities: Another threat that should worry us
IDORs are just one potential threat to your organization's data security, and one that can unfortunately require a lot of manual effort to detect and remediate.
There are many tools that can help you automate your privacy and strengthen your protection against resource-consuming threats like ransomware, freeing up time for your most critical tasks.
