Manual de Burp Suite Community Edition
Capítulo 16 · IDOR: qué es y metodología de caza
Serie: Burp Suite desde cero | unfantasmaenelsistema.com
El capítulo 13 encontró un IDOR real de principio a fin, con dos cuentas. Lo que faltaba era convertir ese hallazgo puntual en un método -algo que se pueda repetir, sin pensarlo de cero, contra cualquier endpoint nuevo de cualquier aplicación. Este capítulo formaliza ese método, y lo pone a prueba de inmediato contra un endpoint que el capítulo 15 dejó anotado y sin explorar: `/api/Complaints`.
Qué aprenderás en este capítulo
La definición formal de IDOR y sus dos variantes: objeto individual y listado sin filtrar · Un método de cuatro pasos aplicable a cualquier endpoint nuevo, no solo a los que ya conoces · Cómo demostrar con una prueba cruzada -no solo con lectura- que un listado no está filtrado por usuario · Por qué el mismo método, aplicado a dos endpoints hermanos, puede dar veredictos opuestos
1. IDOR, otra vez, pero con nombre completo
Insecure Direct Object Reference: una aplicación expone una referencia directa a un objeto interno -un id numérico, un UUID, un nombre de archivo- y resuelve esa referencia sin comprobar que quien pregunta tiene derecho a ver (o tocar) ese objeto en concreto. El capítulo 13 lo mostró en su forma más clásica: un id de usuario en la URL. Pero la misma familia de fallo tiene una segunda variante, menos comentada y no menos común: un endpoint de listado que debería devolver solo lo tuyo, y devuelve todo.
2. El método, en cuatro pasos
| Paso | Qué hacer |
|---|---|
| 1. Localizar | Sacar la lista completa de endpoints con el método del capítulo 15 (bundle JS) en vez de esperar a tropezar con ellos navegando |
| 2. Línea base | Probar el endpoint con tu propia cuenta y anotar exactamente qué devuelve -el objeto esperado, el campo que identifica al dueño (UserId, owner, etc.) |
| 3. Cambiar de identidad | Repetir la MISMA petición con: (a) el token de otra cuenta de igual privilegio -horizontal; (b) una cuenta de menor privilegio -vertical; (c) sin ningún token -anónimo |
| 4. Prueba cruzada en listados | Si el endpoint devuelve una colección, no te fíes de mirar los datos que ya hay -crea tú un registro con una cuenta, con una marca reconocible, y comprueba si OTRA cuenta lo ve en su propio listado |
El paso 4 es el que más se salta -y el que más hace falta
Con un objeto individual (`/api/Users/1`), basta con mirar la respuesta para saber si hay fuga. Con un listado, los datos que ya existen en la base de datos de pruebas pueden confundir: si ves ahí algo que "parece" de otro usuario, no sabes si el endpoint filtra mal o si esos registros nunca tuvieron dueño. Crear tú mismo el dato con una marca única y comprobar si aparece en OTRA cuenta es la única forma de estar seguro.
3. Aplicando el método a un endpoint nuevo
`/api/Complaints` -la queja o reclamación que cualquier cliente puede mandar desde la tienda- salió en la búsqueda del capítulo 15 y se quedó sin probar. Paso 2, línea base: se manda una queja con la cuenta alumno, con un texto que no podría estar ahí por casualidad.
POST /api/Complaints con la cuenta alumno: 201 Created, id 3, mensaje "MARCA_UNICA_DE_CUENTA_A_7f3e91"
Paso 4, la prueba cruzada: la cuenta admin -sin ninguna relación con esa queja- pide su propio listado.
GET /api/Complaints con el token de la cuenta admin: la queja de alumno aparece completa, palabra por palabra
El listado no está filtrado por usuario, es así de simple
No hace falta ningún id que adivinar ni ninguna cabecera que falsificar -el endpoint, tal cual, devuelve TODAS las quejas a CUALQUIER cuenta que pregunte. Es la misma familia de fallo que `/api/Users/` en el capítulo 13 -autenticación sin autorización- pero aquí el síntoma es un listado completo en vez de un objeto suelto por id.
Queda un paso por completar: el caso anónimo, sin ningún token en absoluto.
La misma petición sin cabecera Authorization: 401 Unauthorized -aquí sí hay una comprobación, aunque sea la más básica posible
El veredicto completo, con los cuatro pasos ya aplicados: hace falta estar logueado (paso 3c, bloqueado), pero da igual con qué cuenta -cualquiera ve el listado entero (pasos 2 y 4, sin filtrar). Autenticación sin autorización, otra vez -y va a ser el patrón más repetido de todo este manual.
Conclusión
El mismo método -localizar, línea base, cambiar de identidad, prueba cruzada en listados- dio en el capítulo 13 un veredicto mixto (Addresses protegido, Users no) y aquí un veredicto claro (Complaints no filtra nada salvo la autenticación). Esa es la utilidad real de convertir un hallazgo en método: deja de depender de la suerte de encontrar el endpoint adecuado, y se convierte en algo que se puede repetir contra cualquier superficie nueva -incluida toda la que el capítulo 15 dejó localizada y todavía sin revisar.
El capítulo siguiente da un paso más allá de la lectura: control de acceso roto, horizontal y vertical -qué pasa cuando el objeto ajeno no solo se puede leer, sino también modificar o borrar.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)