> For the complete documentation index, see [llms.txt](https://security-vault.gitbook.io/hacking-methodology/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://security-vault.gitbook.io/hacking-methodology/reconnaissance/attacks/idor.md).

# IDOR

## Insecure Direct Object Reference (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

* <https://hadrian.io/blog/insecure-direct-object-reference-idor-a-deep-dive>
* <https://bugbase.in/blog/casting-light-on-IDOR>