IDOR is one of the most popular and common vulnerabilities, It occurs when an application provides direct access to objects based on user-supplied input. This allows a malicious attacker to access data belonging to other users by manipulating the request.
- Retrieve Data: This allows to retrieve data such as PII {Personally Identified Information}, phone numbers, receipts/invoices, etc
- Modify/Delete Data: This allows to modify someone else’s information such as email address, password, account details, etc.
For example, To view your account on a website with a private profile the URL will be something like https://www.site.com/user=123 Now, if you try to visit the URL https://www.site.com/user=124 and were granted access, that site would be considered vulnerable to an IDOR bug.
The basic idea for finding these types of vulnerabilities is simply looking for the parameters which seem to take a value like an ID, and If the ID is an integer, then try to increment or decrement that ID to check whether you can access the data of other users or not.
If you are using Burp, then this can be automated by sending the request to the intruder and then selecting the ID parameter as payload position and a list of integers as the payload. look for any visual changes that in responses, like a change in Content-Length, If the site is not vulnerable to IDOR then the site will simply return access denied message to all other requests.
Now if the ID is using randomized identifiers, such as universal unique identifiers (UUIDs). In this case, the ID might be a 36 character alpha-numeric string which is impossible to guess. The idea to test for IDOR in this scenario is to create two user-profiles and switch between those accounts testing objects. So, if you are trying to access user profiles with a UUID, create your profile with User 1 and then with User 2, try to access that profile since you know the UUID of both the accounts, try to create different records like files, invoices, images, etc.(according to the functionality of the site) as User 1 and then access those records as User 2 since you know the valid UUIDs between profiles.
If you’re able to access the objects, that is a bug but of low impact, because the IDs are 36 character randomized string and thus impossible to guess. Now the next step would be to try if those IDs are leaked by the website somewhere like check the page source when visiting a profile. Sometimes sites will include a JSON blob for the user which also includes all of the records created by them thereby leaking sensitive UUIDs.
Examples
Retrieving Data →
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// IDOR vulnerability allows an attacker to be able to access/retrieve
// the data which they shouldn't be allowed to.
// For Ex say a website makes the following GET request to an API to access the
// address of the user
https://examplesite.com/api/users/12432/address
{
"id":12432,
"username":"sahil-rawat",
"address":"123, Some Street"
}
// However If There isn't a security mechanism in place, On changing the
// id field in the request, An attacker can Retrieve the data belonging
// to someone else
https://examplesite.com/api/users/1/address
{
"id":1,
"username":"admin",
"address":"874, Some Other Street"
}
✅ The ID could be a numerical integer value or any random char string, we just need to calculate how the id is being calculated (sometimes the ID is the base64 encoded value of the username)
Modifying Data →
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// IDOR vulnerability allows an attacker to be able to modify
// the data which they shouldn't be allowed to.
// For example to change a users email id and username the following PUT request is being
// made to an API endpoint
PUT https://examplesite.com/api/user/profile HTTP/1.1
{
"id":12432,
"username":"sahil",
"email":"[email protected]"
}
Response:{"success":"true"}
// However In case of an IDOR vulnerability, we were able to modify the account details of
// some other user by changing the id value in the request
PUT https://examplesite.com/api/user/profile HTTP/1.1
{
"id":1,
"username":"sahil1",
"email":"[email protected]"
}
Response:{"success":"true"}
Tips
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Some Points to consider while looking for IDORS is:
* Understand how the application works:
* How does it fetches data from the backend
* How it Creates New Data
* How it deletes data
* Look for any numerical IDs in the request
* Create two users to have accurate data (userID, objectID, etc)
* Application may use encryption/encoding to obfuscate userID {ex- base64}
* Automate Using Burp
Sometimes Application uses UUIDs instead of Numeric id's. UUID's are unpredictable
long strings. They look like this: bfe5c6a8-9afa-11ea-bb37-0242ac13002.
They don't protect against IDOR's but they do make it harder to exploit.
Application may leak this UUID, on purpose or by accident. For example, when
you visit another user's profile, they may have a profile photo stored on
the website in a folder the same as their UUID
<img src="/assets/profile_picture/bfe5c6a8-9afa-11ea-bb37-0242ac13002/avatar.png">
Thanks for Reading, Stay tuned for more ❤︎
If you enjoyed reading the article do follow me on: