URL and APIs
The very first step is to identify Direct Object References.
Whenever we receive a specific file or resource, we should study the HTTP requests to look for URL parameters or APIs with an object reference (e.g. ?uid=1
or ?filename=file_1.pdf
).
These are mostly found in URLs and APIs but sometimes found in HTTP headers as well.
We can try incrementing these values of the object references to retrieve other data.
AJAX Calls
We may also be able to identify unused parameters or APIs in the front-end code in the form of JavaScript AJAX calls.
For example, if we did not have an admin account, only the user-level functions would be used, while the admin functions would be disabled. However, we may still be able to find the admin functions if we look into the front-end JavaScript code and may be able to identify AJAX calls to specific end-points or APIs that contain direct object references. If we identify direct object references in the JavaScript code, we can test them for IDOR vulnerabilities.
Following shows a basic example of an AJAX call:
The above function may never be called when we use the web application as a non-admin user. However, if we locate it in the front-end code, we may test it in different ways to see whether we can call it to perform changes, which would indicate that it is vulnerable to IDOR. We can do the same with back-end code if we have access to it (e.g., open-source web applications).
Understand Hashing/Encoding
Some web applications might encode the object references.
e.g ?filename=ZmlsZV8xMjMucGRm
→ base64
We can decode, modify and re-encode.
e.g download.php?filename=c81e728d9d4c2f636f067f89cc14862c
→ Hashed
Looks secure but if we take a look at the source code, we can figure out the encoding method used:
Compare User Roles
If we want to perform more advanced IDOR attacks, we may need to register multiple users and compare their HTTP requests and object references. This may allow us to understand how the URL parameters and unique identifiers are being calculated and then calculate them for other users to gather their data.
For example, if we had access to two different users, one of which can view their salary after making the following API call:
The second user may not have all of these API parameters to replicate the call and should not be able to make the same call as User1
. However, with these details at hand, we can try repeating the same API call while logged in as User2
to see if the web application returns anything.