Insecure Direct Object Reference is a common vulnerability in web applications that allows unauthorized users to access sensitive data or perform unauthorized actions. This vulnerability is often overlooked but can have serious consequences if left unpatched.

This blog will discuss the basics of IDOR, how to identify it, and how to prevent it. We’ll also be sharing real-life examples of IDOR attacks, and the steps organizations can take to protect themselves.

Whether you’re a developer looking to improve your web application’s security or a business owner looking to secure your online assets, this blog has something for you. So let’s dive in and learn more about IDOR!

What is Insecure Direct Object Reference Vulnerability?

IDOR stands for Insecure Direct Object Reference. Insecure direct object references allow attackers to sidestep authorization by changing the reference to a resource so that it points directly to an object, such as a database entry belonging to another user or a file on the system.

Let’s take an example. Imagine you are using a social media platform. You can chat on that platform and are able to view or delete it as well.

An example of an HTTP request to retrieve the Messaging chat could look like this:

GET /messages?user_id=1234 HTTP/1.1

Host: vulnerablesite.com

If an attacker changes the request’s user id with the victim user and can read the victim user’s chat messages, this security flaw is an Insecure Direct Object Reference Vulnerability.  

Impact of IDOR

The impact of an insecure direct object reference vulnerability depends on the application’s functionality. Therefore, a clear list cannot be easily given. Generally speaking, an IDOR vulnerability can introduce a risk for the CIA (confidentiality, integrity, availability) of data.

For instance, a supposed attacker can perform a CURD action on the victim’s user account, being able to view, modify or delete user PII information. The vulnerability severity then goes critical.

If an attacker is able to access limited or non-sensitive information, the vulnerability severity may be considered low or informative.

Where to Look for IDORs?

Remember that IDORs can appear in URL parameters, form field parameters, file paths, headers, and cookies when testing. Capture all the requests going between your web client and the web server.

Inspect each of these requests carefully. Go through each request and test the parameters containing numbers, usernames, or IDs.  

Capture every API request between the client and server. Check for random id values that you might think are sensitive or unique token IDs or user IDs, or document ids from request.

Take the above API request, for instance:

GET /api_v1/messages?user_id=1234

Try to replace your user id with a different user id. Test IDORs with Different HTTP methods.

IDOR via Change the request method

Sometimes developers might fix the simple GET-based IDOR and put proper access controls on it.  There are plenty of other ways to get your data, including GET, POST, PUT and DELETE.

For instance, if the POST Method does not allow you to change another user’s data, then try with different HTTP methods like PUT, and PATCH. Developers often forget to check such methods on mitigation times.

Many applications also have options like deleting the address of the user account or adding an address for the account. 

In such a scenario, you must check for delete methods that are most vulnerable to IDOR. It is possible when assigning a new address id that we can’t check it from request, but many times we can notice that while deleting any document, address, or account, the server returns specific ids that are often missing by other hackers. 

IDOR via HPP (HTTP parameter pollution)

A vulnerability in HPP (HTTP Parameter Pollution) can also lead to IDOR. The application might not expect the user to submit multiple values for the same parameter, and by doing so, you might be able to bypass access control on the endpoint.

GET /api_v1/download_chat?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID

IDOR Restriction bypass via Wrapping ids in Array

IDOR, or Insecure Direct Object References, is a common vulnerability in web applications that occurs when an attacker is able to access sensitive data by manipulating the IDs of objects within the application. This can be done through various methods, such as changing the URL or using a parameter to access data that should not be visible to the attacker.

One method of bypassing IDOR restrictions is known as wrapping IDs in an array. This technique involves placing the object’s ID within an array and then manipulating the array index to access different objects.

For example, if an application has a URL structure such as “example.com/users/[user_id]”, an attacker could wrap the user_id in an array and change the index to access different user accounts.

This technique can be effective in bypassing IDOR restrictions because many applications do not properly validate the array index and will allow access to any object within the array. This can allow an attacker to access sensitive data or perform actions that they should not be able to, such as deleting user accounts or changing information.

To prevent IDOR restriction bypass via wrapping IDs in an array, it is important for developers to properly validate user input and ensure that only authorized users can access sensitive data. This can be done through proper authentication and authorization measures, such as restricting access to certain objects based on user permissions.

It is also important to regularly test and audit the application to identify and fix any vulnerabilities.

Wrap ID with an array {“id”:111} –> {“id”:[111]} * 

JSON wrap {“id”:111} –> {“id”:{“id”:111}} * 

Send ID twice URL?id=<LEGIT>&id=<VICTIM> * 

Send wildcard {“user_id”:”*”}

Prevention for IDOR

To prevent IDOR attacks, it is important to implement proper authentication and authorization controls. This includes verifying that users have the necessary permissions to access certain data and restricting access to only those who are authorized.

Additionally, it is important to validate user input to ensure that it is not malicious and to sanitize any input that is received. This can help prevent attackers from manipulating URL parameters or form submissions in order to gain access to sensitive data.

• Use the auth barrier and CSRF token on every server to request to verify the user’s access. Integrate both the token with each other and verify the user’s proper access control from the server side. 
• The clients must rectify all the errors before delivering the code to the server. If we go for a social media site, it requires an email address and password. The names and email addresses should be in a specific format to minimize all the inputs’ vulnerabilities. This is called fuzz testing. 
• Use hashing salt for user id. Using a hash allows the following properties.
  • They do not require maintaining a mapping table (real ID vs. front-end ID) in the user session or application-level cache.
  • This makes creating a collection of enumeration values more difficult to achieve because even if an attacker can guess the hash algorithm from the ID size, it cannot reproduce the value due to the salt that is not tied to the hidden value.

Conclusion

In conclusion, Insecure Direct Object Reference (IDOR) is a vulnerability that occurs when a user’s request can access an object or resource to which they are not supposed to have access. This can lead to serious security issues and data breaches.

To prevent IDOR, it is important to implement proper access controls and validate user input. This can be done through the use of secure coding practices, input validation, and the implementation of role-based access controls.

By taking these precautions, organizations can reduce the risk of IDOR attacks and protect their sensitive data.

Contact us to know more.