What Are Insecure Direct Object References (IDOR)? Meaning, Working, Mitigation, and Examples

• Insecure direct object reference (IDOR) is defined as an access control vulnerability that occurs when a user input (e.g., account number) is directly linked to an application’s object, and there is no checking mechanism to stop unauthorized users from accessing the object.
• IDORs occur in a surprisingly large number of websites and web-based applications. For example, the Teams vulnerability was found by JUMPSEC Labs in June 2023.
• This article explains how IDORs can be exploited by bad actors and also lists the types of attacks that can take place and how to prevent them.

What Are Insecure Direct Object References (IDOR)?

Insecure direct object reference or IDOR refers to an access control vulnerability that occurs when a user input (e.g., account number) is directly linked to an application’s object, and there is no checking mechanism to stop unauthorized users from accessing the object.

IDORs can have severe effects on cybersecurity and are notoriously tough to locate. However, exploiting them is as easy as manually modifying a URL parameter; for instance, incrementing the account number by 1.

IDORs were popularized by the Open Web Application Security Project (OWASP) several years ago. When composing its list of the ten most damaging web application flaws, OWASP referred to vulnerabilities that permitted attackers to reference objects as IDOR directly. IDORs might permit illegitimate access to application resources, as explained by OWASP.

The OWASP Top 10 for 2007 introduced the distinct category A4 Insecure Direct Object Reference to formalize the basic idea that gaining access to resources and operations is possible by manually altering a URL or form parameter. This category of vulnerabilities was combined with A5 Broken Access Control in 2017.

Currently, IDORs can be categorized as:

• Horizontal IDOR vulnerabilities: When a user possesses data they shouldn’t have at their access levels (e.g., another user’s data).
• Vertical IDOR vulnerabilities: When a user can access datasets that they shouldn’t be able to since the content demands an elevated privilege level, which is termed data access abuse.
• Object-level IDOR vulnerabilities: When a user can alter or remove an object that they shouldn’t have rights to.
• Function-level IDOR vulnerabilities: When a user has access to a feature or action that they shouldn’t have access to.

Simply put, a disclosed direct object reference isn’t inherently hazardous; it merely reveals implementation-specific internal information. To qualify as an IDOR, the direct object reference has to be accompanied by inadequate access control.

Therefore, a direct object reference weakness exists when all three conditions listed below are met:

• Application has an explicit connection to an internal asset or function
• User can alter the direct reference by manipulating a URL or just the form parameter
• Application provides entry into the internal object without verifying the user’s authorization

While this may appear highly complex, it is fairly simple, as discussed below.

See More: What Is Multi-Factor Authentication? Definition, Key Components, and Best Practices

How Does IDOR Work?

IDORs work by allowing hackers to exploit vulnerabilities in how identifiers are used in web-based applications as well as the app’s failure to check for unauthorized access.

• Most web applications refer to server-side objects with straightforward, unique identifiers. For instance, an individual in a database is typically identified using a unique user ID.
• This same user ID is automatically generated as the primary key for the database column carrying user information.
• The algorithm to create database keys relies on basic incrementing, i.e., it generally uses the next known integer. The same mechanisms are used to generate database IDs for every other type of database record.
• In other words, the same ID value helps power identifiers across the system, which can cause a vulnerability.
• Currently, such IDs are often used on the client side; for example, by web-based apps and application programming interfaces (APIs).
• IDs can be transmitted in URLs using standard HTTP GET queries. In such a scenario, the IDs are plainly visible in the web browser and the request headers, making them readily available to threat actors.

The use of direct references to internal IDs is not advised for reasons of security. It might allow intruders to carry out extensive brute-force attacks, such as discovering all user IDs. If there’s no alternative method of referencing an internal object, the programmer must at least action access control. This way, exposing the resource needs more than merely a reference and basic page authentication.

For instance, a web app shows transaction information using the URL:

https://www.examplepage.com/transaction.php?id=13579

A malicious entity can attempt to alter the value of the ID field by substituting other comparable values for 13579.

https://www.ex.com/transaction.php?id=13570

Based on the application, action 13570 may be valid and linked with a different account. In a perfect scenario, the attackers wouldn’t be permitted to view it. If the software developer fails to run authorization tests before giving access to the transactions, the hacker may be able to view it. In a situation like this, an insecure direct object reference (IDOR) vulnerability will likely exist.

See More: What Is Encryption? Definition, Working, and Types

Types of IDOR

IDORs may take different shapes. Some examples include:

1. IDORs that directly reference database objects

Think of a website using the URL mentioned below to get to the customer account page. It pulls data from the backend database, as is evident.

https://www.examplepage.com/customer_account?customer_number=132355

Here, the customer number is specifically employed as a record index in queries against the backend database. A malicious party can readily alter the customer_number value if no other restrictions exist. This would let the perpetrator evade access controls and look at customer records.

This form of IDOR culminates in the horizontal escalation of privileges. In addition to horizontal privilege escalation, an intruder may be able to execute vertical privilege escalation by switching the user to one with more privileges. Once an infiltrator has landed on a user’s account page, other potential outcomes are password leaks or parameter modification.

2. IDORs that directly reference static files

When valuable assets are located in inert files on the server’s file system, IDOR vulnerabilities routinely arise. For instance, a website may save transcripts of conversation messages with an incrementing filename. Then, it could enable users to get back these files by using the following URL:

https://www.examplepage.com/static/12144.txt 

In this scenario, an attacker can access a transcript generated by another user by simply altering the filename. They can grab login credentials and other confidential data.

3. IDORs in POST body instead of URL

In computation, POST is a request mechanism enabled by the Internet’s HTTP protocol. In certain instances, the identifier for sensitive data might not appear in the URL but instead in the POST content. Here’s an example:

<form action=”/update_profile” method=”post”>

<!– Other fields for updating name, email, etc. –>

<input type= “hidden” name= “user_id” value= “12345”>

<button type= “submit”>Update Profile</button>

</form>

The application permits users to modify their personal information by completing a form containing the user ID in a concealed field. However, if the application does not conduct suitable server-side access control, assailants can change the ‘user_id’ field. This IDOR might allow cyber criminals to alter the online identities of others without authorization.

In June 2023, researchers from JUMPSEC Labs found an IDOR of this type in Microsoft Teams. They were able to switch the identifiers for internal and external recipients in the POST body–which usually looks like this: /v1/users/ME/conversations/<RECIPIENT_ID>/messages–to send malware to a trusting user.

4. IDORs that involve object IDs vs. filenames

As noted in the customer number case, IDOR vulnerabilities can also occur with password modification forms. A poorly constructed password modification/change form URL might look like this:

https://www.examplepage.com/change_password.php?userid=1701

This URL will be sent via email after entering an email address through a separate form. Imagine there are no further tests. Malicious attackers could possibly obtain permission to use the administrator account by accessing the URL with userid=1.

In contrast, another type of IDOR may involve a filename instead of the object ID (despite the name object references). Directory traversal ranks as one of the most prevalent IDOR vulnerabilities. In this unique situation, the user can disclose unauthorized assets.

Consider the following URL:

https://www.examplepage.com/display_file.php?file.txt

Suppose the display_file.php script is linked with an IDOR vulnerability, an attacker might gain entry into confidential file system resources by traversing through the directory using the filename as the starting point. A hacker, for instance, could add the ‘/etc/passwd’ file to the URL.

https://www.examplepage.com/display_file.php?../../../etc/passwd

This could reveal passwords stored in files due to the dangerous exposure of filenames.

5. IDORs that provide access to cookies

This category of IDOR allows attackers to steal user data. These cookies may contain their stored passwords and other private information. The only thing the perpetrator must do is change the cookie’s ID in the URL.

http://www.examplepage.com/cookieid=002891981

6. IDORs that allow for direct financial gains

This type of IDOR can enable malicious users to access discounts and privileges that they shouldn’t be able to. Imagine an online retailer sends you an email containing a unique, one-time promotional code for purchasing something from their store.

The data is subsequently turned into a URL, like this one:

http://www.examplepage.com/applydiscount?promocode=123

Assume that the URL gets processed without verifying that the user is eligible for the specified promotional discount. Customers who see this during payment may be forced to enter additional promo codes to check the results. By altering the promo code parameter’s value to, say, 120 or 125 and receiving an alternative discount, it’s possible to profit directly from an IDOR vulnerability.

Identifiers are typically located in headers or application programming interfaces instead of the address bar of a user’s web browser. However, due to the transient nature of most websites, parameters and identifiers continue to be widely used in some form.

IDORs can, therefore, include identifier categories such as database keys, query parameters, individual or session IDs, or filenames.

See More: What Is Spyware? Definition, Types, Removal, and Prevention Best Practices in 2022

Types of IDOR Attacks

Through URLs and form variables, apps can expose confidential data. This can lead to insecure direct object reference (IDOR) attacks, such as:

1. Account takeover

Attackers may carry out unauthorized operations inside an application by altering unauthorized user ID values, command identifiers, or API keys. Examples include imposing a password change to assume control of a user account, running admin actions to add users or upgrade privileges, or getting access to paid services.

2. Data breaches

Direct database IDs can be revealed by exposing object references. This enables attackers to retrieve sensitive information from database records. The names and values of database key columns may also be employed to construct structured query language (SQL) injection packages.

3. Unauthorized file access

This IDOR category usually works with path traversal. allowing an attacker to change file system resources. It could permit them to submit files, influence the data of other users, or obtain premium content free of charge.

4. Object manipulation

Permission to use or access internal object references can enable unauthorized users to alter the application’s internal state and data. As a result of this exposure, intruders might interfere with session variables, possibly changing data or getting access to restricted functionalities. Object manipulation hampers the functionalities of the app.

Even though numerous IDORs have major vulnerabilities in and of themselves, they are usually exploited together with other malicious vectors. In October 2021, for instance, a significant data breach involving ‘stalkerware’ applications and an IDOR attack transpired. The apps collected data from IDOR-impacted systems, exposing the text messages, call logs, pictures, and geolocation data of millions of mobile devices. The vulnerability was named CVE-2022-0732.

See More: Credential Stuffing and Account Takeovers: How Bad Is the Impact on Financial Services?

IDOR Mitigation Best Practices

Insecure direct object references can easily creep into application code. If left unchecked, hackers can exploit them to manipulate app data, files, or operations. That’s why it is important to:

1. Configure your apps to perform whitelist validation on inputs

Web applications must verify all untrustworthy inputs received in response to each HTTP request. The apps you develop should utilize whitelist validation on all inputs, which involves contrasting incoming values to the application’s standards.

This could indicate that:

• Minimum or maximum value
• Minimum and maximum numerical limits
• Acceptable characters
• Types of data such as string, date, integer, and rational
• Patterns such as a telephone number, SS number, and employer identification number

Whitelist validation is also called syntactic validation. This ensures an application imposes checks on each input, which, if unsatisfied, will result in the input being rejected.

2. Replace direct references in-app URLs with indirect ones

Identifiers such as IDs, titles, and keys can also be designed to be substituted with cryptographically secure random values. Both values are stored on the server, and, as such, an app cannot disclose a direct reference to them.

For example, a typical Google Doc ID like https://docs.google.com/document/d/103rvEbSb74guFOXOr4JnhLPQ5TELNX4BpojWdrg/sharing uses a random value in place of the real document ID.

Indirect references offer an elaborate method of counterattack. As such, it is harder for hackers to swap references with relevant values. Due to the time required to carry out cryptography, indirect references can affect your app’s performance.

3. Select your web applications wisely and conduct vendor due diligence

When selecting web-based apps, organizations must do due diligence. This includes following logistics risk management guidelines. Software must only be sourced from trusted vendors who commit to the principles of ‘secure by design’ and ‘-default.’ Before using the product, if provided, inspect the software bill of materials (SBOM) for obsolete, susceptible, or unauthorized applications.

4. Regularly test your network environment

Regular, preemptive penetration testing will ensure the security of network perimeters and web applications. Select web apps accessible via the internet and support authentication for users. Think about using a third-party tester to detect new attack vectors.

Most of the time, dynamic application security testing (DAST) and other security scanners will discover IDOR vulnerabilities in your existing applications. DAST tools use automated penetration testing to evaluate the security apps offer and create automated alerts. Promptly report any identified weaknesses to the supplier or the developer.

5. Always enforce access controls

Users are limited to using information and assets they can access when access controls are in place. This can include role-based, permission-based, and other techniques of access constraints. Internal microservices have to incorporate access control tests. Even though the internal service isn’t available from a public network, it is still out there and is susceptible to attacks. This best practice will prevent insider IDOR attacks in private networks.

6. Make use of security-focused development frameworks

The most effective protection method against IDOR is establishing rigorous access control measures. Fortunately, modern web frameworks such as Ruby on Rails and Django have no problems with IDOR until the developer chooses to use his or her own protocols as opposed to the provided ones. Such frameworks implement access control by dint of their sheer architecture.

Therefore, we suggest you develop web applications using widely used frameworks that combine best practices. Developers should be discouraged from veering from these, even if it is to save time or be a little more efficient.

7. Apply fuzz testing before application release

Fuzz testing is a software testing framework that uses random or unanticipated inputs to discover application defects and vulnerabilities. Apps must be able to effectively process these uncommon inputs without breakdowns or disclosing sensitive data.

Organizations can help detect (but not prevent) unsafe direct object references by reviewing their URLs and database queries with a random number generator. Yelp’s software engineers, for instance, launched the fuzz-lightyear framework that automates the detection of IDOR vulnerabilities.

See More: What Is Application Security? Definition, Types, Testing, and Best Practices

Takeaway

In July 2023, the Australian Cyber Security Centre (ACSC) and the U.S. National Security Agency (NSA), along with several other bodies, issued an advisory surrounding IDOR. It warned software vendors, developers, enterprises, and designers that any web app can be vulnerable to IDORs. As our reliance on Internet connectivity increases and we transmit more and more sensitive data via publicly exposed networks, IDORs need our special attention. It is only by protecting against insecure direct object reference (IDOR) vulnerabilities that we can ensure safe and secure online experiences.

Have you ever encountered a risk or an attack related to IDORs? Tell us on FacebookOpens a new window , XOpens a new window , or LinkedInOpens a new window . We’d love to hear from you!

Image Source: Shutterstock

MORE ON SECURITY THREATS

• What Is Adware? Definition, Removal, and Prevention Best Practices for 2022
• What Is a Brute Force Attack? Definition, Types, Examples, and Prevention Best Practices in 2022
• Dark Web vs. Deep Web: 5 Key Differences
• What Is Advanced Persistent Threat? Definition, Lifecycle, Identification, and Management Best Practices
• What Is a Cyber Threat? Definition, Types, Hunting, Best Practices, and Examples