Insecure Direct Object References (IDOR) occur when a web application exposes a direct reference to an object, like a file or database resource, which the end-user can directly control. This mainly occurs when there is a lack of an access control on the back-end.
URL Parameters
We first have to identify Direct Object References, whenever we receive a specific file or resource we should look at the HTTP requests to look for URL parameters or APIs with an object reference.
An example of this would be ?filename=file_2.pdf
AJAX Calls
Some web applications developed in JavaScript frameworks may insecurely place all function calls on the front-end and use the appropriate ones based on the user role. A non-admin account should only use user-level functions. If we find those admin functions however we may be able to identify AJAX calls to the specific endpoint or APIs.
Hashing/ Encoding
Some web applications may not use simple sequential numbers as object references but may encode or hash it instead. Sometimes the file name is what is being hashed.
Most web applications are developed using JavaScript frameworks, and many developers will often perform sensitive functions on the front-end. If a hash/encoding was being calculated on the front-end we can study the function and then replicate what it’s doing. An example of this
function downloadContract(uid) {
$.redirect("/download.php", {
contract: CryptoJS.MD5(btoa(uid)).toString(),
}, "POST", "_self");
}The function is sending a POST request with the contract parameter hashed with md5. This parameter goes through base64 encoding right before.
Once the hashing or encoding scheme has been determined we need to mass enumerate which values are valid and point us to objects.
User Roles
If want to compare more advanced IDOR attacks, we may need to register multiple users and compare their HTTP requests and object references.
APIs
IDOR Insecure Function Calls enable us to call APIs or execute functions as another user.