Referencias directas a objetos

El patrón es siempre el mismo: la persona autenticada pide un recurso por su identificador (/api/pedidos/20918) y la aplicación lo entrega porque la sesión es válida, sin preguntarse si ese recurso le corresponde. La autenticación funcionó; la autorización a nivel de objeto no existe. En el estándar de debilidades, es la CWE-639, «Authorization Bypass Through User-Controlled Key»: una clave controlada por el usuario que decide a qué dato se accede.

El identificador puede ir en la ruta, en un parámetro, en el cuerpo de la petición o en una cabecera. Y no siempre es un número: puede ser un nombre de archivo, un correo o un código. Para reconocerlo hay que mirar qué parte de la petición cambia el recurso devuelto y, en la respuesta, a quién pertenece lo que llegó.

Abre el laboratorio. El equipo de pruebas hizo pedidos con dos cuentas propias, así que la tabla de pedidos de prueba dice de quién es cada uno. Luego se pidieron varios pedidos con la sesión de la primera cuenta. El hallazgo no es un código 200: es un 200 cuyo contenido pertenece a la otra cuenta.

Descarta los demás por lo que son: un 200 con contenido propio es una consulta normal, y un 404 es un pedido que no existe. Solo queda uno que cumple ambas condiciones.

Ante un IDOR, la reacción habitual es cambiar los números secuenciales por identificadores largos y aleatorios (UUID). Eso corrige una cosa: ya no se puede adivinar el identificador del vecino recorriendo la serie. No corrige la causa, porque la aplicación sigue sin comprobar la propiedad. Quien consiga un identificador ajeno por otra vía —un enlace compartido, un correo reenviado, un registro, otra función de la propia aplicación— leerá el dato igual.

Por eso en el informe se separan dos cosas: lo que facilita la explotación (identificadores previsibles) y lo que es el fallo (ausencia de comprobación). Una buena recomendación pide arreglar lo segundo y, como mejora adicional, lo primero.

Vuelve al laboratorio. La tabla de recursos con identificador resume el resultado de repetir la prueba de la otra cuenta en cada recurso de la aplicación, junto con el formato de su identificador. Aquí está la evidencia que contradice la idea de que «lo aleatorio protege».

Busca el recurso cuyo identificador es aleatorio y que, a pesar de ello, respondió con datos de la otra cuenta del equipo.

El hallazgo que sirve al cliente nombra la función, muestra la evidencia mínima y pide la corrección en el sitio donde se produce. La evidencia mínima aquí es una petición y una respuesta entre cuentas de prueba, que muestren a quién pertenece el dato devuelto. No hace falta —ni es aceptable— recorrer la serie completa ni leer datos de clientes reales para demostrar el alcance: la propia estructura del identificador y la ausencia de comprobación bastan para estimarlo.

La remediación se escribe como control: en el servidor, tras identificar la sesión, cada acceso a un objeto compara su propietario con la persona autenticada (o con los permisos de su rol) y, si no coincide, responde que no existe o que no tiene permiso. Es una regla del servicio, no una tarea de cada pantalla.