Github

IDOR

IDORs are mainly found in web applications and APIs that rely on user-supplied input to access objects directly.

In an IDOR attack, a bad actor would be able to access data that they're not authorised to see, leading to unauthorised data exposure.

Overview

  1. Detection: One needs to identify end-points where user input is used to reference or access internal objects. This can be done by fuzzing, or just studying the application's behaviour.

  2. Exploitation: When an IDOR vulnerability is found, one could edit the object that is being referenced by another value.

Examples and Common Attacks

URL parameter reference

A user called 123 can access their page (that contains all their private data) with the following URL:

https://remote.com/user/123

One could change 123 to 124 and it will show the profile of 124.

Issue: The application directly takes the URL and fetches user details without verifying user sessions or without verifying if the given user has access to the URL.

File access

https://remote.com/uploads/file

Issue: The website takes the file parameter from the user input, resulting in the attacker being able to access any file.

HTTP Parameter Pollution

The request below allows a user to update their profile. If an attacker tried to change the username parameter, they'd get a 401 error.

POST /updateProfile
Host: remote.com
Content-Type: application/x-www-form-urlencoded


username=123&&bio=New Content

In a new request, one can try to add another username parameter to the request right after the first one, allowing the last username parameter to cancel out the first one and forward the request with the new one.

POST /updateProfile
Host: remote.com
Content-Type: application/x-www-form-urlencoded


username=123&username=1235&bio=New Content

Issue: The site is not able to handle two parameters of the same kind and therefore allows the last one to go through.

References

PreviousCRLF InjectionNextFile Inclusion

Last updated