Insecure Direct Object Reference (IDOR) Vulnerability

What is IDOR?

Insecure direct object references (IDOR) are a form of access control vulnerability that occurs when a program directly accesses objects using user-supplied data. Due to its inclusion in the OWASP 2007 Top Ten, the word IDOR became more well-known. It is only one of several implementation problems in access control that might allow access restrictions to be circumvented. Although they can occur in connection with vertical privilege escalation as well, IDOR vulnerabilities are more frequently related to horizontal privilege escalation.

Common Types of IDOR

Identifiers are becoming more frequently seen in headers or APIs rather than directly in a user's address bar. However, because most websites are dynamic, identities and parameters are still widely utilized in some capacity. Among the possible identifiers are:

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

How Does IDOR Work?

In most circumstances, web applications disclose the user ids or user keys in the request or response, allowing the attacker to access or change the data that is available for a specific end user.

To fully comprehend this, think about an example:

In this, the request was sent out by the web application to update end user 50's profile. The updated URL defines the "id" parameter's function, which is in charge of identifying a legitimate, authorized user account. What if we update this request from

to

If the "id" argument is utilized with direct object references, the attacker is made aware of the illegal data and is subjected to unethical behavior. Here, the web server and application are dependent on user input, which is utilized to refer to the objects' faces directly. This was a simple demonstration to help you better understand IDOR.

IDOR Examples

We frequently encounter IDOR in our daily lives, which is a process that uses user-controlled parameter values. Here are a few IDOR examples.

IDOR With Direct Reference to Database Objects

An illustration will help to clarify how this IDOR scenario may arise. Assume for the moment that a website is using the URL listed below to provide a page for an instant customer account.

The access is accomplished by retrieving information from the back-end databases.

In the example link, back-end database queries use the customer number as a record index. Attackers are permitted to change the previously specified value of the customer number and get around the set access restrictions if additional safeguards are absent. They will then have access to other users' information after this has been completed.

This illustration shows how an IDOR vulnerability led to a horizontal privilege escalation. In addition to horizontal privilege escalation, vertical privilege escalation is possible. Attackers must alter the users in both scenarios by giving them more rights so that access controls may be readily disregarded.

Techniques like exploiting password leaks and changing the key parameters can also be used to complete the task after attackers have gained access to the user account.

IDOR With Direct Reference To Static Files

When critical resources are found in static files on the server-side filesystem, IDOR vulnerabilities frequently appear. For instance, a website may save chat message transcripts with an incrementing filename to disc and make them accessible to visitors by way of a URL like this:

In this case, an attacker can acquire a transcript written by another user by simply changing the filename, possibly obtaining user passwords and other sensitive information.

IDOR Vulnerabilities

When a user creates, sends, or receives a request from a server through a web application, there are some HTTP parameters, such as "id," "uid," "pid," etc., that have some unique values that the user has been allocated. Such parameter values may be visible to an attacker via cookies, headers, or captured wifi packets. Through this, an attacker might be able to change these values, and that change could result in IDOR vulnerabilities.

How Do IDOR Vulnerabilities Get Executed?

Let's first talk about the internal workings of a Web application that accesses user account data through SQL's unauthenticated medium.

The attacker can edit the "accounts" parameter in the web application and insert numerous account numbers to access the data by changing the code above.

Attackers frequently employ the Burp Suite Tool to carry out these kinds of attacks.

Follow the steps below:

Step 1: Obtain the Request

An attacker will first choose the website that would be the target of his IDOR assault. The website is then included in the scope and spidered to collect all of the URLs with the desired criteria.

Step 2: Request Parameter Filtering

Following the initial step, we will use the parameter filters to filter our collected requests. The only options available to an attacker for attack execution are that parameter or injection points.

Step 3: Send Request to Repeater

At this stage, if an attacker finds any injection places where they can run IDOR, they will request the repeater. The vulnerable URL may be something like www.abc.com/myaccount/uid=23. In this case, the "UID" appears to be weak.

Step 4: Parameter Tampering

Now that the attacker has access to the weak injection point, they will attempt to carry out the IDOR attack using social engineering or the pattern specified in the injection point. For instance, if an attacker changes uid from 19 to 20, the account of another user with the ID number 20 will be opened.

Types of IDOR Attack

Most IDOR-based attacks operate in similar ways, however, there are small differences in how the identifier is revealed and/or exploited by hackers. Below is a list of the four different types of IDOR attacks:

1. URL Manipulation URL manipulation is the most basic method of exploiting an IDOR vulnerability and typically involves little or no technical knowledge. In this kind of assault, all we have to do is alter the value of a parameter in the address bar of our web browser.

Although the HTTP request may also be modified with tools, the outcome is the same. The server gives an attacker some kind of improper access.

2. Body Manipulation Body manipulation is extremely similar to URL tampering, however, instead of altering the URL, the attacker changes one or more values in the document's body. The values of checkboxes, radio buttons, and other form elements may need to be changed to do this. Potentially, hidden form values might also be modified.

The user ID for the account that is currently logged in may be passed on by a contact in a hidden form field. We can make our request appear to come from a different user if we can change that hidden value before submitting the form.

3. Cookie or JSON ID Manipulation Cookies and JavaScript Object Notation (JSON) are both frequently used behind the scenes to store and communicate data between client and server, which aids in the dynamic nature of online sites. When we log in to a website, the server could save a user or session ID value in a cookie or JSON object. A hacker could alter these values if the application has an IDOR vulnerability.

4. Path Traversal Path traversal, often known as directory traversal, is a special kind of IDOR vulnerability that an attacker may use to access or modify files or directories directly on the server that hosts the web application. This is a more advanced form of IDOR attack than others since it gives users direct access to file system resources rather than database entries. An attacker may be able to read configuration files, get user login information, or even acquire a fully working shell on the target by using path traversal.

Impacts of IDOR Vulnerabilities

Although IDOR vulnerabilities may be easily exploited, the results of this kind of assault could be disastrous. The following are just a few ways an IDOR may affect the confidentiality, integrity, and availability of the data in your company:

Confidentiality - In the event of a successful IDOR attack, the attacker has access to information they shouldn't have. This could be anything from private health information or trade secrets to a discount coupon for frequent customers on a digital storefront.

Integrity - In rare circumstances, an attacker could be able to change data via an IDOR. These attacks frequently change the parameters of an HTTP POST request. A security researcher identified an IDOR vulnerability in 2020 that would have given an attacker access to user accounts on the web servers of the US Department of Defense and allowed them to alter their passwords. Similar flaws can be used by attackers to add unauthorized material, such as fabricated financial data or damning documents, to an unaware user.

Availability - IDOR can be misused to affect the accessibility of resources. Consider a PHP method that allows you to remove files by name from documents. A hacker could be able to rename files and destroy ones they don't even have access to if authorization checks aren't in place.

Identifying IDOR Vulnerabilities

Although IDOR vulnerabilities are frequently easy to exploit, finding them might be challenging for developers. IDOR problems are harder to find than many other common security issues, therefore finding these vulnerabilities may need human security testing. IDOR bugs are harder to find than many other widespread security issues using tools and techniques like automated scanning and code analysis.

Here are a few techniques for spotting vulnerabilities:

• Using a web browser's integrated developer tools to carry out simple tests.
• Increasing the efficiency of manual testing by utilizing a tool like Burp Suite or OWASP ZAP (Open Web Application Security Project Zed Attack Proxy).
• Taking part in a program for vulnerability disclosure.
• Engaging a penetration testing company from outside to examine important online apps

How to Prevent IDOR Vulnerability?

IDOR vulnerabilities can be prevented by eliminating direct object references, performing user input validation, and employing  GUIDs or random identifiers. Although there isn't a perfect method to avoid IDOR vulnerabilities, some of these procedures might be useful.

1. Implementing Appropriate Access Control and Session Management.

The OWASP, the organization that created the term "insecure direct object reference," views IDOR as primarily an access control problem. Even when easily enumerable IDs are used, proper access control checks and session management features should prevent a rogue user from accessing or manipulating data. It may be beneficial to review the OWASP cheat sheets on authentication and authorization.

2. Prevent Using Direct Object References

Using direct object references in your application is frequently seen as poor code, access control considerations aside. This is particularly valid in the case of sensitive information like account numbers, student/employee IDs, etc. Indirect object references, which are frequently implemented as reference maps or hashing, solve IDOR issues by concealing or obscuring the real identity, which stays concealed on the server side. If hashes are utilized, make sure to use a robust and distinctive salt because simple hashing algorithms like MD5 are simple to decipher.

3. Employing GUIDs or Arbitrary Identifiers.

Enumerating a vulnerable direct object reference is simple in programs that employ sequential or iterative identifiers or parameter values. For instance, if you see that my user ID resembles 1011, you can infer that user 1012 already exists. To discover the user you are searching for, you can then pretty easily attempt every potential value between 0000 and 9999 thanks to modern processing power and automation techniques.

Although they make it considerably more difficult to discover and exploit, GUIDs and globally unique identifiers do not fix the fundamental problem. It is significantly harder to interpret an identification like q232325c-eq76-4825-a2v6-1a716b485w2a than anything easier.

4. Verifying User Input

Validating user input can reduce a variety of security problems, including IDOR. If we tightly validate user-supplied parameters for appropriate length and format, the enumeration of IDs becomes significantly more challenging. Depending on what is necessary, validation might occur either on the client side or the server side.