IDOR is a vulnerability where user inputs reveal app objects and allow hackers to break in easily.
Chiradeep BasuMallick Technical Writer
January 16, 2024
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:
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:
While this may appear highly complex, it is fairly simple, as discussed below.
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.
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:
A malicious entity can attempt to alter the value of the ID field by substituting other comparable values for 13579.
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.
IDORs may take different shapes. Some examples include:
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.
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.
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:
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.
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:
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//messages–to send malware to a trusting user.
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:
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:
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.
This could reveal passwords stored in files due to the dangerous exposure of filenames.
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.
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:
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.
Through URLs and form variables, apps can expose confidential data. This can lead to insecure direct object reference (IDOR) attacks, such as:
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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 Facebook Opens a new window , X Opens a new window , or LinkedIn Opens a new window . We’d love to hear from you!
Image Source: Shutterstock
