# URL Params & APIs
- The first step to exploiting IDOR vulns is identifying IDORs
- 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 URL parameters or APIs but may also be found in other HTTP headers, like cookies
- In basic cases, we can try incrementing the values of the object references to retrieve other data, like (`?uid=2`) or (`?filename=file_2.pdf`)
- Also use a fuzzing to try thousands of variations and see if they return any 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
- Some web apps developed in JavaScript frameworks may insecurely place all function calls on the front-end and use the appropriate ones based on the user role
- 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
- But, 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
- Example showing a basic example of an AJAX call
```javascript
function changeUserPassword() {
$.ajax({
url:"change_password.php",
type: "post",
dataType: "json",
data: {uid: user.uid, password: user.password, is_admin: is_admin},
success:function(result){
//
}
});
}
```
- 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
# Understanding Hashing & Encoding
- Instead of using simple sequential numbers as object references, web apps may encode the reference or hash it instead
- If we find such parameters using encoded or hashed values, we may still be able to exploit them if there is no access control system on the back-end
- Example javascript code where filename is being hashed before API call is made
```javascript
$.ajax({
url:"download.php",
type: "post",
dataType: "json",
data: {filename: CryptoJS.MD5('file_1.pdf').toString()},
success:function(result){
//
}
});
```
# Compare User Roles
- When performing 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
- Assuming, for example, we have access to two different users, one of which can view their salary after making the following API call
```json
{
"attributes" :
{
"type" : "salary",
"url" : "/services/data/salaries/users/1"
},
"Id" : "1",
"Name" : "User1"
}
```
- 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
- Notably, such cases may work if the web apps only requires a valid logged-in session to make the API call but has no access control on the back-end to compare the caller's session with the data being called