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

# IDOR

### ¿Qué es una vulnerabilidad IDOR?

**IDOR** significa *Insecure Direct Object Reference* (Referencia Directa Insegura a Objetos) y es un tipo de **vulnerabilidad de control de acceso**.\
Este tipo de fallo ocurre cuando una aplicación web permite que el usuario acceda a objetos (como archivos, datos o documentos) directamente mediante un identificador proporcionado por el cliente, **sin validar adecuadamente en el servidor si ese objeto realmente le pertenece** al usuario que lo solicita.

#### Ejemplo ilustrativo

Imagina que te registras en un servicio online y quieres cambiar tu información personal. Haces clic en un enlace que apunta a:

```
http://online-service.thm/profile?user_id=1305
```

y puedes ver tu propio perfil.

Por curiosidad, decides cambiar el valor del parámetro `user_id` a 1000:

```
http://online-service.thm/profile?user_id=1000
```

Y para tu sorpresa, ahora puedes ver el perfil de **otro usuario**.\
¡Acabas de descubrir una vulnerabilidad IDOR!\
En un sistema seguro, **el servidor debería verificar que el ID consultado realmente pertenece al usuario autenticado**.

***

### IDs Codificados

Cuando los desarrolladores web transmiten datos entre páginas (por POST, query strings o cookies), a menudo **codifican** esos datos para que el servidor pueda interpretarlos correctamente. Una forma muy común de hacerlo es mediante **Base64**.

Por ejemplo, el ID `123` codificado en Base64 es:

```
MTIz
```

Puedes detectar fácilmente este tipo de codificación, ya que suele usar caracteres como `a-z`, `A-Z`, `0-9` y el símbolo `=` como relleno.

Herramientas útiles para decodificar y modificar estos valores:

* <https://www.base64decode.org/>
* <https://www.base64encode.org/>

Con estas herramientas puedes:

1. Decodificar el valor.
2. Cambiarlo por otro ID.
3. Volver a codificarlo.
4. Reenviar la solicitud web y observar si accedes a datos ajenos.

***

### IDs Hasheados

Algunas veces los identificadores no están codificados, sino **hasheados**, lo que los hace un poco más difíciles de reconocer. Por ejemplo, el ID `123` si se hashea con MD5 se convierte en:

```
202cb962ac59075b964b07152d234b70
```

Aunque parezca aleatorio, muchos hashes siguen un patrón predecible. Puedes usar servicios como:

* <https://crackstation.net/>

Este sitio intenta descifrar hashes conocidos utilizando una base de datos gigantesca de valores hasheados previamente.

***

### IDs Impredecibles

Si el ID no puede ser identificado fácilmente como un número, un valor codificado o un hash conocido, puedes detectar un IDOR usando una técnica simple:

1. **Crea dos cuentas** en la aplicación.
2. Accede a un recurso desde una cuenta y copia el ID.
3. Cierra sesión o inicia con la otra cuenta.
4. Intenta acceder al recurso anterior usando el ID copiado.

Si puedes ver el contenido del otro usuario, **has encontrado una vulnerabilidad IDOR válida**.

***

### ¿Dónde suelen encontrarse estas vulnerabilidades?

No siempre es evidente. A veces los endpoints vulnerables no están directamente en la barra de direcciones del navegador. Podrían estar:

* En solicitudes AJAX cargadas en segundo plano.
* Referenciadas en archivos JavaScript.
* Ocultas como parámetros que fueron usados durante el desarrollo y llegaron a producción.

#### Ejemplo realista

Estás autenticado y ves que tu información se carga desde:

```
/user/details
```

Pero haciendo **parameter mining** (búsqueda de parámetros ocultos), descubres que puedes acceder a otros usuarios usando:

```
/user/details?user_id=123
```

Esto confirma una vulnerabilidad IDOR, ya que se está accediendo a recursos sin la validación adecuada de permisos.