El escáner con sesión

Un escaneo sin sesión solo ve la parte pública. El informe de Mirasol lo muestra: con la cuenta de pruebas, el escáner descubre muchas más URL y encuentra alertas que antes no existían, porque las pantallas de «mi cuenta» y de «mis entradas» estaban fuera de su vista. Para que el escáner entre se le configura un usuario de pruebas, el método para iniciar sesión (aquí un formulario) y dos expresiones que le permiten saber en cada respuesta si sigue dentro o si lo han sacado.

El usuario es una cuenta del entorno de pruebas, creada para el escáner, con los permisos mínimos que haga falta ver. Nunca una cuenta de una persona ni, desde luego, una de producción.

La cuenta del escáner tiene una clave, y esa clave sigue siendo un secreto: si el plan vive en el repositorio, la clave no puede estar escrita en él. El plan vigente de Mirasol la pide como una variable que el almacén de secretos del pipeline inyecta al ejecutar. Es la misma disciplina del módulo de secretos aplicada a una herramienta de seguridad: la herramienta que busca secretos no puede ser quien los deja caer.

En el historial del repositorio quedó el plan anterior. Para encontrar la mala práctica hay que mirar donde ya no se mira.

Una araña sigue todos los enlaces, y uno de ellos es el de «cerrar sesión». En cuanto lo pide, el servidor invalida la sesión y, desde ese momento, todo lo que el escáner pida responderá con una redirección al inicio de sesión. Parece un escaneo con sesión y es uno sin ella: coste de tiempo, cero cobertura. Se detecta en el registro, por el cambio de respuestas 200 a redirecciones, y se evita excluyendo del escaneo la ruta de salida.

Las expresiones de «sesión iniciada» y «sesión cerrada» del plan existen para eso: que el escáner note que la perdió y vuelva a entrar. Cuando la verificación falla, nadie se entera hasta leer el registro.

Medir lo que se perdió convierte una sospecha en un argumento. El registro dice cuántas peticiones hizo el escáner en total y cuál fue la que le cerró la sesión; todas las posteriores se hicieron sin sesión, y por tanto no cuentan como prueba de lo que hay detrás del inicio de sesión.

El informe de comparación tiene una línea inquietante: doce respuestas de «acceso denegado» en las rutas de administración. No son un hallazgo ni un error del escáner: son el sistema funcionando. La cuenta de pruebas tiene rol de cliente, y el panel de administración le está cerrado. Eso significa que esa parte de la aplicación no se ha probado. Para probarla haría falta una segunda cuenta de pruebas con rol de administración, y decidir, con el responsable, si esa parte entra en el alcance.