Insecure Direct Object Reference (IDOR)

What is an Insecure Direct Object Reference (IDOR) Risk?

 IDOR stands for Insecure Direct Object Reference occurring when an application displays an indication of an internal object in an unsafe manner. Whenever a user generates, sends an HTTP request, or receives a request from a server, there are parameters such as “ID”, “UID”, “PID” etc. that have certain unique values that the user has been assigned. An attacker may detect such parameter values in HTTP paths, cookies, and headers. With this, the attacker can tamper with other privileges of user data and this interference can lead to Insecure Direct Object Reference Vulnerability.

Figure 1: IDOR Flow

 

What are HTTP methods and what are they used for?

HTTP defines a set of request methods to indicate the desired action to be used for a given service. In simple terms “It is a method of communication between server-side and client-side”

Figure 1.1: HTTP Methods

In general, Insecure Direct Object Reference (IDOR) has three types of attack vectors:

• Body Manipulation. Attackers can change the value of the input box, radio buttons, and form fields. This allows them to access other users’ information more easily.
• URL Tampering. The URL is changed at the client-side by tempering parameters on the HTTP request. HTTP GET and POST actions are often at risk of URL tampering attacks that lead to IDOR attacks in applications.
• JSON IDs manipulation.
  • APIs and small services that will work with a structured data format like JSON may be vulnerable to IDOR flaws and errors.
  • To read other users’ data, especially if they rely on some obvious form of a session to validate applications.

 

Here we can see how Insecure Direct Object Reference (IDOR) works in the modern web application, we test PortSwigger lab for this attack.

This is the official URL: https://acc91f8f1f83a99b805b1001001c0052.web-security-academy.net to access the lab.

For solving this lab, we need to get the password of CARLOS via IDOR vulnerability.

 

1. Click on the live chat button.

2. Click on the send button and observe messages.

3. Click on view transcript and capture the request in Burpsuite.

4. Forward this request.

5. After forward we will get this endpoint path /download-transcript/3.txt

6. Change the endpoint path 3.txt to 1.txt and forward it.

7. Now as we can see we are successfully able to download the 1.txt file of CARLOS.

8. Open this txt file and we can see the CARLOS password in it.

9. Now try to login with CARLOS account using this password.

10. As you can see, I am successfully able to login into the CARLOS account and solved the challenge.

 

Impact of the Insecure Direct Object Reference Vulnerability:

• As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.
• Such resources can be database entries belonging to other users, files in the system, etc.
• An attacker can steal sensitive information from unrestricted directories and use this to craft other attacks.

 

Mitigation of the Insecure Direct Object Reference Vulnerability:

• Engineers should avoid showing references to secret objects such as keys or file names.
• Parameter validation should be used correctly.
• Verification of all indicated items must be done and implement Authentication/Authorization in the application.
• Tokens should be generated in such a way that they should be edited to the user only and should not be public.

 

References: 

• https://portswigger.net/web-security/access-control/idor
• https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

 

Author,

Rituraj Vishwakarma

Attack & PenTest Team

Varutra Consulting Pvt. Ltd