Learn About Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR), also known as broken object level authorization, is a vulnerability that arises when a web application exposes a direct reference to an internal implementation object, such as a file, directory, or database key. It's like leaving a treasure chest unlocked, allowing anyone with the right map (or URL) to access its valuable contents.

Understanding IDOR: The Basics

IDOR vulnerabilities occur when an application fails to properly check if a user is authorized to access a specific resource. Instead, it relies on the user-supplied input (e.g., a file name or ID) to directly access the resource. This can allow attackers to access or modify data belonging to other users or even the application itself.

The Anatomy of an IDOR Attack

1. User Input: The attacker identifies a parameter in a URL, form, or API request that appears to reference a specific object.
2. Direct Reference: The application uses this parameter to directly fetch the corresponding object without performing any authorization checks.
3. Unauthorized Access: The attacker modifies the parameter to reference a different object that they are not authorized to access.
4. Attacker's Gain: The attacker can now view, modify, or delete the unauthorized object, potentially leading to data breaches, account takeovers, or other malicious activities.

Types of IDOR Vulnerabilities

1. URL-Based IDOR: The vulnerable parameter is part of the URL.
2. Form-Based IDOR: The vulnerable parameter is part of a form submission.
3. API-Based IDOR: The vulnerable parameter is part of an API request.

Impact of IDOR Attacks

IDOR vulnerabilities can have severe consequences, including:

● Data Breach: Attackers can access sensitive data, such as personal information, financial records, or confidential documents.
● Account Takeover: Attackers can gain control of other users' accounts by accessing and modifying their profile information or settings.
● Financial Fraud: Attackers can make unauthorized purchases or transactions if the application handles financial data.
● Data Manipulation: Attackers can modify or delete data belonging to other users or the application itself, causing disruptions or damage.

Identifying and Exploiting IDOR Vulnerabilities

1. Manual Testing:
○ Analyze the application's URLs, forms, and API requests for parameters that reference objects.
○ Try modifying these parameters to see if you can access objects belonging to other users or the application itself.
○ Look for patterns in object identifiers (e.g., sequential numbers, predictable file names).
Automated Scanning:
○ Use web vulnerability scanners like Burp Suite or OWASP ZAP to automate the process of finding IDOR vulnerabilities. However, manual testing is often more effective for discovering subtle IDOR issues.

2. Automated Scanning:

○ Use web vulnerability scanners like Burp Suite or OWASP ZAP to automate the process of finding IDOR vulnerabilities. However, manual testing is often more effective for discovering subtle IDOR issues.

Example Payloads:

https://vulnerable-website.com/view_profile?user_id=123
https://vulnerable-website.com/download_invoice?invoice_id=456

Mitigating IDOR Attacks

● Authorization Checks:Always perform authorization checks before granting access to any object.
● Indirect Object References: Use indirect object references (e.g., random tokens or UUIDs) instead of direct references (e.g., sequential IDs).
● Input Validation: Validate and sanitize all user input to prevent injection attacks.
● Logging and Monitoring: Implement logging and monitoring to detect and respond to unauthorized access attempts.

IDOR in Bug Hunting

Insecure Direct Object Reference Vulnerability (IDOR Vulnerability) is one of the most important vulnerabilities included in the top 10 OWASP list. We shall talk about the IDOR Vulnerability in this essay. Prior to proceeding, let us talk about authentication. Verifying an individual's identity and granting them access to particular requests only occurs when a user has been authenticated (verified). However, it is known as "broken authentication" when a user lacks authentication and is able to read files—that is, open files incorrectly, much like hackers and attackers do. The use of broken authentication vulnerabilities by attackers that could result in IDOR will be the main topic of this paper.

An IDOR vulnerability: What is it?

When a user creates, submits, or receives a request from a server through a web application, some HTTP parameters—like "id," "uid," "pid," and so on—have specific values that are allocated to the user. Cookies, headers, and wifi packet captures can all reveal such parameter values to an attacker. This may allow an attacker to manipulate these settings, which could result in IDOR.

Several instances illustrating how IDOR can be used to modify untrusted data include:

vulnerable.com/myaccount/uid=12
vulnerable.com/myaccount/uid=14
vulnerable.com/myaccount/uid=15
vulnerable.com/myaccount/uid=19

As we can see, the uid in the URL appears to be weak and might be altered by an attacker in order to bypass authentication.

IDORs can be represented as follows:

**1. Directory Traversal: Also referred to as a Path Traversal attack, Directory Traversal allows an attacker to access or change files and folders that shouldn't be made available to the general public. A web application's Directory Traversal vulnerability makes it simple for an attacker to view private files and directories, including themes, scripts, photos, and more.
2. Body Manipulation: This term describes the act of altering or updating values within the body, such as checkboxes, radio buttons, input fields, etc.
** 3. URL Tampering: This is the act of altering a URL's parameter value. Assume, for illustration purposes, that there exists an example URL, such as http://example.com/category/photos_id=1. We are permitted to view the ID '1' data in this parameter. However, it might be deemed URL tampering if we were able to alter the value from 1 to 2, for example, http://example.com/category/photos_id=2, and if we were able to view the data associated with this specific URL.
**4. Cookie ID manipulation: **Cookies are often used by clients and servers to store and exchange data. It facilitates the identification of particular visitors and offers them a positive browsing experience. In some situations, manipulating a cookie ID might be possible if there is an IDOR vulnerability. In a web application, for instance, the cookie id for user a might be _gid=123456 and the cookie id for user b might be _gid =789012. Thus, there is an IDOR if user A is able to modify the value of _gid, swap out user b's ID, and view any data that is related to user b.

How Are IDOR Vulnerabilities Put into Practice?

First, let's talk about how a Web application that accesses user account information through the unauthenticated medium in SQL operates on the back end.

String query = "SELECT * FROM 
accts WHERE account = ?";
PreparedStatement pstmt = 
connection.prepareStatement(query, ... );
pstmt.setString(1,
 request.getParameter("acct"));
ResultSet results = 
pstmt.executeQuery( );

The attacker can get information by entering numerous account numbers in the web application's "accts" parameter, which will be modified by the code mentioned above.

Procedures for Carrying Out an IDOR Attack

Attackers frequently utilize the Burp Suite Tool to carry out these kinds of attacks. The actions being taken are as follows:

Record the request: An attacker will first choose the target website that he wishes to use for his IDOR assault. Subsequently, the website is included in the scope and is crawled to obtain all URLs containing specified parameters.
Sort the request's parameters: Using the parameter filters, we will refine our recorded request following the initial stage. Only that parameter or the injection points where they can carry out the attacks will be chosen by an attacker.
Send request to Repeater: An attacker will now send the request to the repeater if they manage to locate any injection locations where they can carry out IDOR. This is how the vulnerable URL may appear: vulnerable.com/myaccount/uid=19. The "UID" appears to be weak in this situation.
Tampering of Parameters: Using social engineering or the pattern that is written in the injection point, the attacker will attempt to carry out the IDOR attack now that they have the susceptible injection point. An attacker may, for instance, alter a user's identification number from 19 to 20, opening the account of a different user who was given ID number 20.

**Let's now use a real-world example to show IDOR. **

● Check out the lab-insecure-direct-object-references at https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references
● Once logged in, select "Access the lab"
● Select "Live chat" now. You will notice that there is a chatbot available. Now text anything to that chatbot at random.

● Launch Burp Suite at this point, and record the request to see the transcript.
● Navigate to the HTTP history tab in the Burp Suite and select the captured request of the download transcript.

● Click "Send" to send the request to the repeater. There, you may view your chat history.

● The URL file that appears after the GET argument is 2.txt, assuming you can see it now. Let's see what happens if we alter the value to 1.txt

● As you can see, the credentials are being leaked via the highlighted text in the answer tab. To check if we can access this user, let's use this password to log into the website with carlos as username.

We can now access the user dashboard and successfully modify the email address there. Thus, it validates the existence of the IDOR vulnerability.

Additional Tips for Bug Bounty Hunters:

** ● Think like an attacker:** Put yourself in the shoes of an attacker and try to think of ways to manipulate parameters to access unauthorized objects.
** ● Look for hidden parameters:** Some parameters may be hidden in forms or API requests. Use browser developer tools or proxy tools to inspect traffic and uncover hidden parameters.
** ● Test different user roles: **Try accessing objects with different user roles to see if there are any inconsistencies in authorization checks.

Let's dive into more examples of Insecure Direct Object References (IDOR) vulnerabilities:

Common IDOR Scenarios

** ● File Downloads:** A website allows users to download invoices. The URL might look like: https://example.com/download?invoice_id=123. An attacker could try changing the invoice_id to access invoices belonging to other users.
** ● Password Reset Links: **Some password reset mechanisms include the user's ID directly in the URL. An attacker who intercepts the link could change the ID to reset another user's password.
** ● Viewing Other Users' Profiles: If a social networking site uses predictable URLs like https://example.com/profile?user_id=567, an attacker could increment or decrement the user_id to view profiles they shouldn't have access to.
** ● Editing Shopping Cart Items: E-commerce sites sometimes expose cart item IDs in URLs. An attacker could tamper with these IDs to modify the price or quantity of items before checkout.

More Advanced Examples

** ● Horizontal Privilege Escalation: An attacker with a regular user account might discover an IDOR in the administrative interface. By manipulating object references, they could gain access to admin functions.
** ● Vertical Privilege Escalation: In some cases, IDORs can allow a low-privilege user to access data or functions meant for higher-privilege users, essentially "escalating" their privileges within the system.
** ● Data Modification: **IDORs can sometimes be used to modify data, not just view it. This could be disastrous if it affects sensitive information like financial records or medical data.

Key Points to Remember

● IDORs are often considered low-hanging fruit for attackers because they can be relatively easy to spot and exploit.
● The impact of an IDOR can vary widely depending on the type of data it exposes and the level of access it grants.
● Developers can prevent IDORs by implementing proper access controls and validating all user-supplied input.

IDOR is one of my favourite vulnerabilities to find. Most companies have a lot of mechanism to defend from this and it's not so common to find nowadays on big companies. However, once you find, you will make bank $ - Last interesting IDOR I found was a couple of months ago on Private company and they paid me $1,300!

Happy hunting!

Author: Ayush khatkar is a cybersecurity researcher, technical writer and an enthusiastic pen-tester at Asecurity. Contact here.

#bugbounty #infosec #cybersecurity