IDOR / Broken Access Control

Un IDOR (Insecure Direct Object Reference) es un fallo de control de acceso: la aplicación expone una referencia directa a un objeto interno (un id, un GUID, un nombre de fichero) y no comprueba que el usuario que la pide tenga derecho a ese objeto. Cambiando la referencia, el atacante accede a datos o acciones de otros usuarios. Es la forma más común de Broken Access Control, el primer puesto del OWASP Top 10.

El patrón

Endpoints del estilo /api/v1/user/1, /invoice?id=42 o /download?file=... donde basta incrementar o sustituir el identificador:

curl -s http://<ip>/api/v1/user/1 -H "Authorization: Bearer <token>" | jq   # ¿datos de otro usuario?
curl -s http://<ip>/api/v1/user/2 -H "Authorization: Bearer <token>" | jq

Cuando el id no es secuencial sino un UUID/GUID, el IDOR sigue vivo si ese identificador se filtra en otra respuesta (un listado, un campo oculto, una cabecera). El truco es recolectar los IDs de un sitio y reutilizarlos donde no deberían valer.

Más allá de leer

Un IDOR no se limita a la lectura. Si el identificador filtrado se reutiliza para autorizar otra operación, el impacto se multiplica: en Backend, el GUID del admin obtenido por IDOR era justo lo que el endpoint /updatepass usaba para decidir a quién cambiar la contraseña, lo que permitió tomar la cuenta del admin sin conocer su contraseña. Variantes cercanas:

• Method tampering: repetir la petición con PUT/DELETE/PATCH cuando el GET está protegido pero los otros verbos no.
• Mass assignment: añadir campos no previstos al JSON ("role":"admin", "isAdmin":true) que el backend acepta sin filtrar.
• Forced browsing: acceder a rutas de administración adivinadas (/admin, /api/internal) que solo se ocultan, no se protegen.

Cómo encontrarlos y automatizar

Comparar respuestas al variar identificadores, fijarse en UUID que parezcan secretos pero se filtren, y revisar cada acción sensible preguntando "¿valida el servidor que este objeto es mío?". Para escalar el barrido, Burp Intruder recorre rangos de id y la extensión Autorize repite cada petición con la sesión de un usuario de menor privilegio y marca las que no deberían responder.

Requisitos

Una referencia a objeto controlable por el cliente y un backend que no reautoriza por objeto. No hace falta escalar privilegios de sesión: el fallo es que la sesión que ya se tiene alcanza objetos ajenos.

Cómo detectarlo. El servidor ve a un usuario accediendo secuencial o masivamente a objetos que no le pertenecen: muchas peticiones a /user/1, /user/2, /user/3... desde una misma sesión, o una cuenta que lee/edita recursos de otros IDs en poco tiempo. La firma es el desajuste entre el sujeto autenticado y el propietario del objeto solicitado, algo que solo se detecta si la app registra ambos. Respuestas 200 a objetos ajenos, o un pico de 403/404 por forced browsing, son las señales en el log.

Defensa. Comprobar la autorización en el servidor para cada objeto y acción (no confiar en que el id venga del cliente), usar referencias indirectas por sesión, y no exponer identificadores que luego sirvan para autorizar. Relacionado con la reutilización de credenciales cuando el IDOR filtra secretos reutilizables y con la fuga de información en APIs.