When a web server processes a user’s request, it determines the resource being accessed by using parameters stated within the HTTP request. The direct object reference is the information used to locate and access a particular resource. While the server is retrieving a resource, attackers can manipulate these parameters and access internal implementation object details in the event of a lack of adequate server-side validation. This attack is known as an Insecure Direct Object Reference (IDOR) vulnerability.
This article explains what Insecure Direct Object References are, their impacts, and possible remediation plans.
Don’t have time to read? Listen to this blog post instead.
What is Insecure Direct Object Reference?
An Insecure Direct Object Reference flaw occurs when the server fails to validate incoming HTTP requests to access objects. Since the application cannot determine the authenticity of the user trying to access an object, it reveals the underlying object details to the attackers. Attackers thereby gain unauthorized access to the object and modify the value of the ID parameter for the object to fulfill their adversary acts. As a result, users can be redirected to access harmful pages without their knowledge. In the worst case, users’ sensitive personal and financial details can also be compromised.
The Insecure Direct Object References vulnerability arises as a consequence of three security gaps:
1. A client can alter user-supplied input such as a form or URL parameter values to modify an object reference
2. The web server exposes a direct reference to an internal operation or object
3. The application lacks sufficient authorization checks for access to internal objects
Since object references expose data of the application’s internal implementation details, the consequences of the attack can be severe.
Some impacts of a successful IDOR attack include:
1. Unauthorized access to sensitive data – Object references often include database IDs, which attackers can access to expose sensitive information about the application/users. The unauthorized user can also use database entries to prepare malicious SQL payloads for further attacks.
2. Object manipulation – With access to internal references, attackers gain direct access to the data and state of the application. Attackers can then manipulate the exposed objects to modify data, access hidden functions, or further escalate privileges.
3. Direct file access – Malicious users can combine IDOR attacks with directory transversal attack techniques to manipulate the host’s file system. This grants them the ability to upload/download files freely and manipulate content accessed by other users.
Types of IDOR Attack
There are several ways through which hackers can orchestrate an IDOR attack. These include:
Body Manipulation
In this type of IDOR attack, the adversary accesses information from other users by modifying the value of checkboxes, API endpoints, radio buttons, and input form fields.
URL Tampering Attacks
The attacker alters HTTP request parameters by modifying URL parameters on the client-side. The URL tampering attack targets the GET and POST parameters since they are generally vulnerable to pollution of a URL parameter.
JSON ID Manipulation
JSON is a popular framework for data exchange between different host machines. The framework is mainly used to send data between a web server and web applications. An attacker may intercept JSON data sent between APIs, servers, and the web application to gain unauthorized access to application configuration and data.
Mass Assignment
Attackers manipulate a record pattern to modify large data sets that they are not authorized to access.
Insecure Direct Object Reference Remediation
Some approaches to mitigate an Insecure Direct Object Reference vulnerability include:
Perform User Request Validation
Without appropriate access checks at data access layers, the webserver cannot assess whether a URL/resource request has been modified. The server should implement authorization and access controls to ensure the request belongs to a user with permission to access the object. Validation checks should be enforced, encompassing all measures to identify malicious user input. Below are some criteria for syntactic validations that can be used to determine the trustworthiness of a request:
1. Minimum or maximum length of the resource
2. Acceptable characters
3. Supported data types
4. The request’s upper and lower boundaries, commonly implemented for numeric values
Different programming languages and frameworks offer varying techniques to determine whether the URL query string, input form values, or checkboxes have been tampered with. Observing these best practices for every access control check helps prevent IDOR attack vectors.
Use Indirect Object Reference Maps
An indirect reference substitutes the direct internal reference in the URL with an alternate ID. An alternate ID can be any random value like GUID or anything specific to the user’s business case. The map refrains the application from exposing internal object identifiers since it acts as an intermediary between the client input data and the server-side processed data. Developers create the indirect reference map and maintain it securely on the webserver. It denotes the relationships between each ID and its substitution. Each object ID in the request is translated to its relevant substitution when sent through the browser. During the processing of user requests, the substitution is translated to the original ID key to be used for access to resources by the server.
Avoid Predictable References
While using an indirect reference map, it is recommended to avoid using references that can be anticipated easily, thereby preventing an attacker from crafting malicious requests. Developers should use Globally Unique Identifiers (GUIDs) as a best practice to identify reference objects. A GUID is a defined hexadecimal number that can go up to 128 bits in size, enabling the creation of random numbers that is almost always unique.
Perform Regular Tests
The OWASP Testing Guide offers information on checking for direct object reference flaws. Checking for flaws requires manual testing of potential requests that the application/client can undertake to validate whether the webserver processes them. The Crashtest Security Suite enables the identification of IDOR security vulnerabilities by providing an automated scanner that helps identify gaps in server validation and access control vulnerability. The platform helps perform a comprehensive scan of the webserver, APIs, and source code to ensure there are no injection points for IDOR attacks. Sign up for a free trial here to evaluate how Crashtest Security can help reduce the IDOR attack surface of your web application.
FAQ
What is the difference between IDOR and Broken Object Level Access (BOLA) attacks?
While they can be used interchangeably in most scenarios, BOLA covers a broader range of application security attacks targeting objects with weak or missing access controls. While IDOR attacks are purposed only at specific resource IDs, BOLA attacks also involve the manipulation of user IDs to gain unauthorized access to data and resources.
This article has already been published on https://crashtest-security.com/insecure-direct-object-reference-idor/ and has been authorized by Crashtest Security for a republish.
Featured Image Courtesy – Photo by Blake Connally on Unsplash
