What is IDOR (Insecure Direct Object Reference)?

As a wide-eyed junior in college, my chance encounter with an IDOR vulnerability introduced me to the world of ethical hacking. 

Insecure direct object references are common, potentially devastating vulnerabilities resulting from broken 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 filename. 

As we learn more about my villain origin story in this blog, we’ll answer key questions like, “What is IDOR?”, “How do I find an IDOR vulnerability?”, and “What can I do to protect against an IDOR?”

• How IDOR works
• Common types of IDOR
• Identifying IDOR vulnerabilities
• Types of IDOR attacks
• Impacts of IDOR
• Preventing IDOR vulnerabilities

How an IDOR vulnerability works

To get a better understanding of how an attacker can exploit an IDOR vulnerability, let’s take a look at my real-world example. As a third-year journalism student, I read about a situation in which a student at a different university accessed the records of other students just by changing a portion of the address in his browser. Intrigued, I decided to see if my university’s own systems suffered from a similar vulnerability. 

To test this, I logged into my student account and noted that just like the story I’d read, the application was using my student ID as an identifier to retrieve my class schedule, grades, and other personal information. The URL looked something like this:

https://stateuniversity.example/GetStudentRecords?ID=00123456789

But what if I simply replaced the “ID=00123456789” portion of the URL with the ID of a different student? After receiving permission, I gave it a go. Sure enough, the system served up her records instead of mine. 

Repeating this process revealed that it was quite simple to pull the records of any university student or employee as long as I knew (or could guess) their student or employee ID. Given the sensitive data that was being exposed, I reported the vulnerability to the university right away.

Just like a plane crash, quite a few things had to go wrong in order for me to pull off this “hack.” First, the application obviously didn't include any authorization checks to see whether I should have access to the records I requested — that’s where the “insecure” in insecure direct object reference comes from. 

Secondly, the university designed its application to base lookups of database records solely on the student/employee ID — there’s the “direct object reference.” Finally, the IDs were listed in the address bar in an easy-to-recognize format, making it simple for even a cybersecurity novice to manipulate. 

Four common types of IDOR

These days, identifiers are more commonly found in headers or APIs than right in a user’s address bar. However, the dynamic nature of most websites means that identifiers and parameters are still heavily used in some form or another. Identifiers might include:

• Database keys
• Query parameters 
• User or session IDs
• Filenames

How to identify IDOR vulnerabilities

IDOR vulnerabilities are often simple to exploit but can be difficult for developers to identify. Tools and techniques like code analysis and automated scanning aren’t as good at spotting IDOR bugs as many other common security issues, which means identifying these vulnerabilities may require manual security testing. 

Some ways to identify vulnerabilities include:

• Performing basic tests using the built-in developer tools in a web browser
• Using a tool like Burp Suite or the Open Web Application Security Project Zed Attack Proxy (OWASP ZAP) to increase the effectiveness of manual testing
• Participating in a vulnerability disclosure program
• Hiring an external penetration testing firm to review critical web applications

Four types of IDOR attacks

Conceptually, most attacks that exploit IDOR work in similar fashions, but there are minor nuances in which the identifier is exposed and/or manipulated by hackers:

1. URL tampering 

URL tampering 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 our web browser’s address bar. 

In my college example, I changed my own student ID to that of other students, professors, and employees at the university. Tools can also be used to modify the HTTP request, but the end result is the same: the server grants some type of inappropriate access to an attacker. 

I had the advantage of knowing a few of these IDs ahead of time — a real attacker would likely spend time enumerating different values and trying to discern a predictable pattern.

Below: A simple URL tampering attack might consist of changing a single parameter ID in an address bar.  

2. Body manipulation

Body manipulation is very similar to URL tampering, except that the attacker is modifying one or more values in the body of the document instead of in the URL. This can mean changing the values of radio buttons, checkboxes, or other form elements. It might also be possible to change hidden form values. 

Perhaps a contact has a hidden form value that passes on the user ID for the currently logged-in account. If we can change that hidden value prior to form submission, we can make our request appear to come from a different user.

3. Cookie or JSON ID manipulation

Cookies and JavaScript Object Notation (JSON) are both widely used behind the scenes to store and exchange data between client and server, helping make web pages more dynamic. When we log into 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 leverages to access or manipulate files or folders directly on the server that runs 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 IDOR impacts data

IDOR vulnerabilities can be simple to exploit, but the impacts of this type of attack are potentially catastrophic. Below are just a few ways an IDOR can impact the confidentiality, integrity, and availability of your organization’s data:

• Confidentiality - As we saw in my university example, a successful IDOR attack gives an attacker access to something they shouldn’t be able to view. This could be anything from a discount code for frequent shoppers on a digital storefront to sensitive personal health information or trade secrets. 
• Integrity - In some cases, an attacker might be able to use an IDOR to modify data. Usually, these types of attacks manipulate parameters in an HTTP POST request. In 2020, a security researcher discovered an IDOR vulnerability that would have allowed an attacker to change the password of user accounts on U.S. Department of Defense web servers. Attackers can use similar vulnerabilities to add unauthorized data such as falsified financial information or incriminating documents onto an unsuspecting user.
• Availability - IDOR can also be abused to impact the availability of resources. Imagine a function in a PHP application that deletes documents by filename. Without proper authorization checks, an attacker may be able to change the filename 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. Though there’s no foolproof solution when it comes to how to prevent IDOR vulnerabilities, some of these steps can help.   

1. Implement proper access control and session management  

The OWASP, which coined the term “insecure direct object reference,” considers IDOR to be an access control issue above all else. Proper access control checks and session management features should prevent a malicious user from being able to access or manipulate data, even when easy-to-enumerate identifiers are used. The OWASP cheat sheets on authorization and authentication can be helpful to review. 

2. Avoid direct object references

Access control issues aside, using direct object references in your application is often considered a sloppy coding practice. This is especially true when it comes to sensitive data like student/employee IDs, account numbers, etc. Indirect object references — often in the form of either reference maps or hashing — address IDOR vulnerabilities by hiding or obfuscating the true identifier, which remains hidden on the server side. If hashes are used, be sure to include a strong and unique salt, as basic hashing algorithms like MD5 are easy to reverse. 

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 piece of cake. If I notice my user ID looks something like 0001, for example, I can make an educated guess that there’s a user 0002. Modern computing power and automation techniques make it fairly easy to then try every possible value from 0000 to 9999 until I find the user I’m looking for.

Neither GUIDs nor universally unique identifiers remove the underlying vulnerability, but they do make it much harder to enumerate and exploit. An identifier like f492325c-ae75-4335-a2a6-1a716b723f2a is much more difficult to decipher than something less complex.

4. Validate user input

User input validation can help to mitigate a wide number of security issues, including IDOR. Enumeration of identifiers becomes much more difficult if we‘re strictly validating user-supplied parameters for proper length and format. Validation can take place on either the client side or server side depending on what‘s most appropriate.

IDOR vulnerabilities: Just one more threat to worry about

IDOR are just one potential threat to your organization’s data security, and one that can, unfortunately, require a lot of manual effort to identify and remediate.

Fortunately, tools like the Varonis Data Security Platform can help you automate privacy compliance and enhance protection against resource-consuming threats like ransomware, saving your limited hours for the most critical tasks. Book a demo today to see how Varonis can amplify the efficiency of your security teams!