Guía de IDOR para principiantes

¿Qué es un IDOR?

IDOR (Insecure Direct Object Reference) es una de las vulnerabilidades más comunes y más recompensadas en programas de bug bounty. Ocurre cuando una aplicación expone una referencia directa a un objeto interno — como un ID de usuario, un nombre de archivo o una clave de base de datos — sin verificar que el usuario tenga autorización para acceder a ese recurso.

En términos simples: si puedes cambiar un número en una URL o en una petición y acceder a datos de otro usuario, probablemente estés frente a un IDOR.

Tipos de IDOR

IDOR Horizontal

Es el tipo más frecuente. Un usuario accede a recursos de otro usuario del mismo nivel de privilegios. Por ejemplo:

GET /api/users/1234/profile    → Tu perfil
GET /api/users/1235/profile    → Perfil de otro usuario (¡sin autorización!)

IDOR Vertical

Ocurre cuando un usuario con privilegios bajos accede a funciones de un usuario con privilegios altos (por ejemplo, un usuario normal accede a un panel de administrador):

GET /api/admin/users           → Solo debería ser accesible para admins
GET /api/admin/settings        → Configuraciones del sistema

IDOR basado en función

No siempre se trata de acceder a datos. A veces puedes ejecutar acciones sobre recursos ajenos:

DELETE /api/posts/5678         → Borrar el post de otro usuario
PUT /api/users/1235/email      → Cambiar el email de otro usuario

¿Cómo encontrar IDORs?

1. Mapear todos los endpoints

Usa Burp Suite para interceptar todas las peticiones mientras navegas la aplicación. Presta especial atención a cualquier parámetro que contenga IDs, UUIDs, nombres de archivo o referencias a objetos.

2. Identificar parámetros sospechosos

Busca patrones como:

/api/v1/users/{user_id}/orders
/api/v1/documents/{doc_id}/download
/api/v1/invoices?id=12345
/profile?account=usuario123

3. Usar dos cuentas

Esta es la técnica más efectiva. Crea dos cuentas de prueba (Account A y Account B):

1. Inicia sesión con Account A y captura las peticiones
2. Copia las peticiones y reemplaza los IDs con los de Account B
3. Envía la petición modificada con las cookies/tokens de Account A
4. Si obtienes datos de Account B, tienes un IDOR

4. Fuzzing de parámetros

Si los IDs son numéricos y secuenciales, prueba con Burp Intruder:

GET /api/users/§1§/profile HTTP/1.1
Authorization: Bearer tu_token_aqui

Payload: Numbers, From 1 To 1000, Step 1

5. Probar diferentes formatos de ID

A veces el mismo endpoint acepta diferentes formatos:

/api/users/123          → ID numérico
/api/users/user_123     → ID con prefijo
/api/users/abc-def-ghi  → UUID
/api/users/admin@test.com → Email como identificador

Ubicaciones comunes de IDORs

• Endpoints de perfil: /api/users/{id}, /profile/{id}
• Descarga de archivos: /api/files/{file_id}/download, /documents/{name}.pdf
• APIs REST: Operaciones CRUD sobre cualquier recurso
• Funciones de exportación: /api/export?report_id=123
• Mensajes y notificaciones: /api/messages/{id}, /api/notifications/{id}
• Historial de transacciones: /api/transactions/{id}
• Endpoints de GraphQL: Queries que aceptan IDs como variables

Bypass de protecciones comunes

Si la primera prueba no funciona, intenta estas variaciones:

# Cambiar el método HTTP
GET → POST, PUT, PATCH

# Agregar/quitar parámetros
/api/users/123 → /api/users/123?admin=true

# Cambiar el formato del ID
123 → 0123 → 00123

# Encodear el ID
123 → MTIz (Base64)

# Probar con el ID en diferentes ubicaciones
Body, URL, Headers, Cookies

Consejos para escribir buenos reportes

1. Describe el impacto claramente: "Un atacante puede acceder a la información personal (nombre, email, dirección) de cualquier usuario de la plataforma"
2. Incluye pasos de reproducción detallados: Paso a paso, con capturas de pantalla
3. Muestra las peticiones HTTP completas: Incluye headers, body y respuesta
4. Demuestra con dos cuentas: Muestra que Account A accede a datos de Account B
5. Clasifica la severidad correctamente: Un IDOR que expone datos bancarios no es lo mismo que uno que expone avatares públicos

Herramientas recomendadas

• Burp Suite: Para interceptar y modificar peticiones
• Autorize (extensión de Burp): Automatiza pruebas de autorización
• FFUF: Para fuzzing rápido de endpoints
• Postman: Para organizar y repetir peticiones

Conclusión

Los IDORs son vulnerabilidades "simples" en concepto pero extremadamente impactantes. Son una excelente puerta de entrada al mundo del bug bounty porque no requieren conocimientos técnicos muy avanzados, pero sí requieren paciencia, metodología y atención al detalle. Practica con las plataformas de labs y pronto estarás reportando tus primeros bugs reales.