Referencia directa a objeto insegura (IDOR)

La aplicación expone un asa a un objeto almacenado: el id numérico de una fila, un nombre de fichero, la referencia de un documento, un número de cuenta. El cliente devuelve esa asa y el servidor la usa para buscar el objeto. El fallo no es que el asa sea visible. El fallo es que esa búsqueda es la única comprobación que se hace, de modo que el servidor responde a la pregunta «¿existe este registro?» en lugar de a la pregunta «¿puede quien llama ver este registro?».

La explotación es aritmética. Incrementar el identificador, repetir la petición con tu propia sesión válida y leer la respuesta. Con enteros consecutivos, enumerar la tabla entera resulta trivial. Los identificadores largos y aleatorios hacen impracticable adivinarlos pero no arreglan nada, porque los identificadores se filtran por exportaciones, enlaces de compartición, resultados de búsqueda y otros endpoints. Por eso el remedio no es la oscuridad, sino la autorización. En un informe de API este mismo defecto se redacta normalmente como autorización rota a nivel de objeto, que es el nombre que usa la lista de OWASP.

El patrón que más encontramos es una aplicación que lo hace bien en la pantalla en la que los desarrolladores pensaron y mal en todas las demás. La lectura está protegida y el borrado no. La vista HTML comprueba la propiedad y el endpoint JSON que hay detrás no. El objeto principal está protegido y el adjunto, el registro de auditoría, el PDF de la factura o el trabajo de exportación no.

El segundo patrón es una comprobación que se ejecuta en el sitio equivocado. Una aplicación que filtra la vista de lista por tenant parece correcta hasta que pides un identificador que nunca estuvo en tu lista, porque el manejador de detalle da por hecho que solo pudiste obtener el identificador desde la lista. En una prueba, este suele ser el camino más rápido hasta los datos de otro cliente, y no necesita exploit, ni herramientas, ni escalada de privilegios: dos cuentas y un proxy.

Pedimos dos cuentas precisamente para poder demostrar esta clase de fallo. La reproducción en el informe es la cuenta A emitiendo una petición que pertenece a la cuenta B, con la respuesta enseñando los datos de B, y la misma petición repetida tras cerrar sesión para separar una comprobación rota de una comprobación ausente. Anotamos qué verbos estaban afectados, porque una exposición de solo lectura y un acceso de escritura son hallazgos distintos. El número de registros alcanzables decide la severidad. Esto forma parte de cómo probamos el acceso a nivel de objeto en una API.