Como @Arminus dijo en un comentario, esto no es una fijación de sesión. La reparación de la sesión es relativamente rara hoy en día, ya que se basa en un comportamiento ahora (afortunadamente) ampliamente reconocido como inseguro / estúpido: cuando inicia sesión, el servidor conserva el token antiguo (JSESSIONID, en este caso) en lugar de generar uno nuevo. Un atacante puede abusar de eso al conocer el valor del token anterior (por ejemplo, porque fue el último usuario) y luego cerrar la sesión y esperar a que llegue un nuevo usuario; cuando el nuevo usuario inicia sesión, conserva el token anterior.
Una vulnerabilidad de seguridad requiere que alguien haga algo para lo que no está autorizado. En su escenario, ¿cómo diablos encuentra el usuario no administrador el JSESSIONID del administrador? Si son la misma persona, entonces el usuario (presumiblemente) ya está autorizado para iniciar sesión como administrador (lo hicieron en la otra máquina, después de todo), por lo que no se ha producido ninguna omisión de seguridad . Si no son la misma persona, tampoco el administrador no robó el JSESSIONID del administrador (en cuyo caso la vulnerabilidad de seguridad está en cómo lo robaron , lo que podría ser su culpa o podría deberse a que la computadora del usuario del administrador tiene spyware), o el usuario administrador compartió el JSESSIONID con el no administrador (lo que significa que el administrador está, esencialmente, sustituyendo al no administrador como usuario temporal de la cuenta del administrador).
Los tokens de autenticación (JSESSIONID, en su caso) tienen una serie de propiedades críticas. La siguiente lista no está en ningún orden en particular. Los relevantes aquí están resaltados:
- Se generan de forma segura (es decir, no use
java.util.Random , que tiene un resultado predecible; use java.security.SecureRandom ). Algunas implementaciones utilizan cadenas de información de usuario encriptadas en lugar de tokens aleatorios; esto tiene algunos riesgos de seguridad bastante malos.
- Son lo suficientemente largos como para que no puedan ser forzados por la fuerza bruta (64 bits generalmente se ven como límites; 128 bits en adelante son buenos).
-
Nunca se reutilizan, por lo que un atacante que ve a uno viejo no puede usarlo para obtener la sesión de otra persona. Como no es factible mantener un registro de todos los tokens de sesión anteriores, la solución es nuevamente use un token lo suficientemente largo (aleatorio) de que las probabilidades de una colisión son infinitesimales (y si expresa las probabilidades de que suceda usando palabras como "mil millones", no es lo suficientemente infinitesimal).
- Deben verificarse de manera constante (de lo contrario, forzar brutalmente un token válido se vuelve lineal en su longitud, en lugar de exponencial).
-
No deben compartirse a través de niveles de privilegio o sesiones para un usuario determinado. Cada vez que un usuario se vuelva a autenticar, el token anterior debe ser invalidado y, en su lugar, debe utilizarse uno nuevo.
-
La invalidación de token debe ocurrir en el servidor. Si un usuario cierra la sesión o su sesión caduca (o finaliza de otra manera), el servidor ya no debe reconocer el token como válido. Simplemente eliminar el token del cliente es no suficiente.
- Los tokens nunca deben enviarse en una URL, solo en encabezados o si es necesario en los cuerpos de los mensajes. Incluso a través de HTTPS, las URL tienden a filtrarse (pueden ser registradas por proxies, incluidas en encabezados de referencia, o guardadas en el historial del navegador, entre otros riesgos). Si se debe enviar un valor seguro absolutamente debe en una URL, debe ser de un solo uso e invalidado después del primer intento de usarlo, ya sea que el usuario haya completado su acción o no, y también debe expirar. muy rápidamente.
- Los tokens nunca deben enviarse a través de conexiones inseguras. Si su sitio admite HTTPS, entonces el token nunca debe enviarse a través de una conexión que no sea HTTPS (una forma fácil de asegurarse de que es tener el token en una cookie y establecer el indicador
secure en esa cookie). Si su sitio no es compatible con HTTPS, trate las sesiones como conveniencia solamente; No hay seguridad real allí. ( Sí, mirándote a ti, comportamiento predeterminado de autenticación posterior de SE ... )
Probablemente me estoy olvidando de algunos, pero una lista completa no es el punto central aquí. Sin embargo, como puede ver, hay un montón de cosas (algunas relacionadas y otras independientes) necesarias para un token de autenticación seguro, que es solo un componente de un sitio seguro. Tienes que hacerlas todas; un enlace débil suele ser suficiente para que un atacante ingrese.