IDOR in APIs

IDOR in APIs

Insecure Direct Object Reference (IDOR) is a vulnerability that arises when attackers can access or modify objects by manipulating identifiers used in a web application’s URLs or parameters. It occurs due to missing access control checks, which fail to verify whether a user should be allowed to access specific data.

An API endpoint is vulnerable if:

• It exposes sensitive object properties to users who shouldn’t have access to them.
• It permits users to modify, add, or delete values of sensitive object properties that they shouldn’t be able to access.

Common security issues arise when:

• Access control privileges, like roles, are included in the client’s HTTP request, potentially under their control.
• Insufficient backend access control -> assigning user roles -> privilege escalation.

Impact

Unauthorized access to private or sensitive object properties can have serious consequences, including:

• Data disclosure: Exposing confidential information to unauthorized parties.
• Data loss: Unintended deletion or manipulation of sensitive data.
• Data corruption: Unauthorized modification of critical data leading to integrity issues.
• Privilege escalation: Unauthorized access may allow attackers to gain higher levels of access or privileges within the system.
• Account takeover: In some cases, unauthorized access can lead to partial or complete control over user accounts, posing significant security risks.

Prevention

1. Ensure API endpoints only expose object properties accessible to users.
2. Avoid generic methods like to_json() and to_string(); instead, selectively choose properties for return.
3. Prevent mass assignment by avoiding automatic binding of client input to internal objects or properties.
4. Limit client updates to only permissible object properties.
5. Implement schema-based response validation for added security.

Side Notes

1. HTTP methods commonly utilized in APIs are:

• PUT -> update item details.
• POST -> create new items.
• DELETE -> delete items.
• GET -> retrieve item details.

2. Try to test the API against IDOR Information Disclosure vulnerabilities by attempting to get other users’ details with GET requests.

Scenario (Lab): Vulnerable API Call in the Update Profile Function

Identifying Vulnerable Apis

1. change details in our profile and click Update profile.
2. intercept the Update request.
3. PUT request to the /api/profile/1 includes hidden parameters, like uid, uuid, and role.
4. observe that role set to employee.

Now, how would we know what other roles exist?

Exploitation

There are a few things we could try:

1. Change our uid to another user’s uid.
2. Change another user’s details.
3. Create new users with arbitrary details.
4. Delete existing users.
5. Change our role to a more privileged role (e.g. admin).

Steps

Changing our uid to another user’s uid:

Change our (“uid”: 1) to another user’s uid (e.g. “uid”: 2) -> uid mismatch.

app appears to be comparing the request’s uid to the API endpoint (/1)

Changing another user’s details:

Change the API endpoint to /profile/2, and change “uid”: 2 to avoid the previous uid mismatch -> uuid mismatch.

app appears to be checking if the uuid value we are sending matches the user’s uuid

Creating new users with with a POST request

Change the uid a new uid (e.g. “uid”: 20 ) & the API endpoint (/20) -> admins-only action.

Deleting existing users with a DELETE request

Change the uid to another uid (e.g. “uid”: 20 ) & the API endpoint (/20) -> admins-only action.

Changing our role to a more privileged role (e.g. admin)

Change our role to admin/administrator to gain higher privileges -> Invalid role.

It seems that all our attempts have been unsuccessful.

But, if there’s no solid access control preventing us from reading other users’ details, we might be able to get IDOR Info Disclosure then use this information to complete our IDOR attacks on the function calls.

Send a get request to the API endpoint ending with (/profile/10):

We’ve discovered an Information Disclosure vulnerability revealing admin details, which could be significant.

IDOR Information Disclosure

1. Let’s use this information to alter the admin details:

2. Send a get request again to the updated details API endpoint ending with (/profile/10):

We’ve successfully updated the admin staff details.

Let’s try to Create new users by bypassing access control privileges with role as (“role”:”staff_admin”)

Creating new users with with a POST request as “role”:”staff_admin”

1. Change the uid a new uid (e.g. “uid”: 20 ) & the API endpoint (/20) -> 200 OK!

We’ve successfully bypassed the restriction that only admins can create new employees.

2. Update the role and details of the new user:

3. Send a GET request to the API endpoint for the updated details of the new user (/profile/20):

Successfully chaining IDOR Information Disclosure with IDOR Insecure Function Calls vulnerabilities enabled unauthorized actions to be performed.

Additional Resources

• Insecure Direct Object Reference Prevention — OWASP Cheat Sheet Series
• API3:2023 Broken Object Property Level Authorization — OWASP API Security Top 10

Thanks for Reading!

• Twitter