Insecure Direct Object Reference (IDOR) Vulnerability

IDOR happens when a web application uses user-supplied input (like an ID, account number, or file name) to directly access objects in the backend without properly checking whether the user is authorized to do so.

• Every user has their own resources (like profile, documents, or account details).
• The app identifies these resources with an identifier (e.g., userId=123).
• If the app does not check “Does this user really own or have permission to see this resource?”, then attackers can just change the identifier (e.g., userId=124) and access other users’ data.

Some of the examples that demonstrate the untrusted data which can be manipulated using IDOR:  

www.xyz.com/myaccount/uid=12
www.xyz.com/myaccount/uid=14
www.xyz.com/myaccount/uid=15
www.xyz.com/myaccount/uid=19

Here we can see that the uid in the URL seems to be vulnerable and can be tampered with by an attacker to break the authentication. 

Types of IDOR 

There are four types of IDOR as follows:

1. Directory Traversal: Directory Traversal is also known as a Path Traversal attack where an attacker can access or manipulates the files and folders which should not be allowed to access publicly. If there is a Directory Traversal vulnerability exists in a web application then the attacker can easily able to see some sensitive files or folders such as images, themes, scripts, and so on. 
2. Body Manipulation: Body Manipulation refers to changing or modifying the values in the body such as modifying the values of input fields, radio buttons, checkboxes, etc. 
3. URL Tampering: URL Tampering refers to changing the parameter value of the URL. For example, let's suppose there's an example URL that may be something like 'http://example.com/category/photos_id=1'. In this parameter, we are authorized to see the data of ID '1'. But if we could change the value from 1 to 2 such as 'http://example.com/category/photos_id=2', and if we could see the data of this particular URL, in such case it can be considered as URL Tampering. 
4. Cookie ID Manipulation: Generally, cookies are used to store and exchange data between the client and server. It helps in identifying specific users and provides a good browsing experience to the user. In such cases, if there's an IDOR vulnerability then there might be a possibility to manipulate a cookie ID. For example, there's a cookie id in a web application that may be something like this _gid=123456 which is for user a, and another cookie id is _gid=789012 which is for user b. So, if user A can change the value of _gid and replace the ID of user b and can see any information which belongs to user b then there's an IDOR. 

How do IDOR Vulnerabilities Get Executed? 

Let us first discuss the back-end working of a Web application that uses the unauthenticated medium in SQL, which leads to accessing user account information.  

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

In the above code, the attacker will modify the "accts" parameter in the web application and can enter multiple account numbers to retrieve the information. 

Steps Involved in the Execution of the IDOR Attack

Burp Suite Tool is widely used by attackers to execute such types of Attacks. Following are the steps being followed:  

• Capture the Request: First of all, an the attacker selects a target site, adds it to Burp's scope, and spiders the site to enumerate URLs and parameters.
• Filter the parameters Request: After the first step, from the captured traffic, the attacker filters for requests that contain parameters. They focus on parameters that look like injection points or resource identifiers.
• Forward request to Repeater: Now, if an attacker will find some of the injection points where they can execute IDOR, they will forward the request to the repeater. The vulnerable URL might look something like this: www.xyz.com/myaccount/uid=19. Here the "UID" seems to be vulnerable.
• Tampering of Parameters: Now as the attacker has the vulnerable injection point, they will now try to execute the IDOR attack with the help of Social engineering or the pattern as written in the injection point. Example: an attacker may change uid from 19 to 20 which will open the account of another user who has been assigned id number 20.

Now, let's demonstrate IDOR with a practical scenario. 

• Below is the link to launch the lab on PortSwigger:

Lab: Insecure direct object references

• After logging in click on access lab 
• Now click on live chat. You'll get to see a chatbot is connected. Now just randomly text anything to that chatbot

• Now open the burp suite and capture the request to view the transcript.
• In the burp suite go to the HTTP history tab and click on captured request of download transcript. 

• Now send the request to the repeater and click on send. You can see your chat details there.

• Now if you can observe the URL file after GET parameter it's 4.txt. Let's change the value to 1.txt and see what happens.

Now if you could observe the highlighted text in the response tab, it's leaking the passwords. Let's log in to the website by using this password and see if we could access this user. 

Now here we get access to the user dashboard and here we have successfully changed the email address. So it confirms that there's IDOR vulnerability exists. 

Impacts of IDOR Vulnerability

• Exposure of Confidential Information: If an attacker gains control of your account through this vulnerability, they can access sensitive personal information.
• Authentication Bypass: This vulnerability allows attackers to access multiple user accounts without valid credentials, effectively bypassing authentication controls.
• Alteration of Data: Attackers with access privileges can modify or manipulate your data. This could lead to unauthorized changes, corruption of records, or fraudulent activity.
• Account Takeover: By incrementing or modifying the UID values, attackers can take over multiple user accounts. When one exploited vulnerability leads to another (as in this case), it is referred to as bug chaining.

Remediation of IDOR Vulnerability

• Do not expose private object references (keys, file names, internal IDs).
• Implement strict parameter validation.
• Verify referenced objects before use.
• Issue user-bound tokens only.
• Use unpredictable identifiers.
• Sanitize and validate all user input.