What's an IDOR
IDOR, or Insecure Direct Object Reference, refers to a security vulnerability that arises when an application's access control mechanism does not properly validate and enforce authorization restrictions on direct object references. In simpler terms, it means that an attacker can manipulate an identifier (such as an ID or key) used to access an object directly, bypassing the intended access controls.
This vulnerability allows an attacker to access or modify sensitive information, such as other users' private data, files, or resources, which they should not have authorized access to. It occurs when the application fails to verify the user's permissions or the ownership of the requested object before granting access.
The impact of an IDOR vulnerability can range from unauthorized data exposure to unauthorized actions on sensitive resources. Therefore, it is crucial for developers to implement proper authorization checks and access controls to mitigate the risk of IDOR vulnerabilities.
IDOR Example
Imagine you have recently registered for an online service and wish to modify your profile details. Clicking on the provided link directs you to http://online-service.thm/profile?user_id=1305, where you can access and view your own information.
Driven by curiosity, you decide to experiment by changing the user_id value to 1000 in the URL http://online-service.thm/profile?user_id=1000. Surprisingly, you find that you can now see the information of another user. This discovery indicates the existence of an IDOR vulnerability within the system. Ideally, the website should implement a mechanism to validate that the requested user information belongs to the logged-in user, thereby preventing unauthorized access to other users' data.
Finding IDORs in Encoded IDs
Encoded IDs
When transferring data between web pages, developers often employ encoding techniques to ensure the proper understanding of the content by the receiving web server. Encoding involves converting raw data into an ASCII string, typically utilizing characters from a-z, A-Z, 0-9, and = for padding. This transformation allows for safe data transmission.
One widely used encoding method on the web is base64 encoding, which is easily identifiable. To manipulate encoded data, you can use websites like https://www.base64decode.org/ to decode the string, make the necessary modifications, and then re-encode it using https://www.base64encode.org/. By resubmitting the modified data in a web request, you can observe if there are any changes in the response.
Graphical example of this process:
Finding IDORs In Hashed IDs
Hashed IDs
Although encoded IDs are simpler to handle compared to hashed ones, hashed IDs can sometimes exhibit a predictable structure, such as being the hashed version of the integer value. For instance, if md5 hashing was employed, the ID number 123 would transform into 202cb962ac59075b964b07152d234b70.
Finding IDORs in Unpredictable IDs
Unpredictable IDs
To detect IDOR (Insecure Direct Object Reference) vulnerabilities when the above methods fail, a reliable approach involves creating two accounts and interchanging the ID numbers associated with them. By attempting to access the content of other users using their ID numbers while remaining logged in with a different account or even without being logged in at all, you can identify potential instances of IDOR vulnerabilities. If successful, and you are able to view the content of other users, it indicates the presence of a valid IDOR vulnerability.
Where're IDORs Located
Where are they located?
The vulnerable endpoint you're targeting may not always be something you see in the address bar. It could be content your browser loads in via an AJAX request or something that you find referenced in a JavaScript file.
Sometimes endpoints could have an unreferenced parameter that may have been of some use during development and got pushed to production. For example, you may notice a call to /user/details displaying your user information (authenticated through your session). But through an attack known as parameter mining, you discover a parameter called user_id that you can use to display other users' information, for example, /user/details?user_id=123.
Practical IDOR Example
In the Your Account section, you have the option to modify your personal details, including your username, email address, and password. When you access this section, you'll observe that the username and email fields are already populated or pre-filled with your information.
To begin our investigation into the pre-filling of this information, let's utilize the browser developer tools. Open the tools, navigate to the network tab, and then refresh the page. Upon doing so, a request will be made to an endpoint with the path /api/v1/customer?id={user_id}, revealing how the information is obtained and populated.
This page returns in JSON format your user id, username and email address. We can see from the path that the user information shown is taken from the query string's id parameter (see below image).
"IDOR-Ex1 1.png" is not created yet. Click to create.
We can try testing this id parameter for an IDOR vulnerability by changing the id to another user's id.
we can dig trough the source code and get a look at the function that is responsible for getting the username and email from the database.
