Secuestro de sesión (Session hijacking)
En seguridad web y de identidad, el secuestro de sesión es el robo y la reutilización del token que demuestra que un usuario ya ha iniciado sesión. El atacante no llega a conocer la contraseña y no se enfrenta nunca al formulario de acceso: presenta la sesión robada y la aplicación le trata como al usuario que la creó.
Cómo funciona
Tras la autenticación el servidor emite un portador de algún tipo, normalmente una cookie con un identificador de sesión o un token firmado. A partir de ahí la credencial es ese valor, no la contraseña, y quien lo tenga es el usuario hasta que caduque o se revoque. Cuatro vías lo consiguen. Un script que corre en el origen lo lee, que es cross-site scripting contra una cookie sin la marca HttpOnly. Malware en el endpoint lo saca del perfil del navegador, que es para lo que está hecho un infostealer. Un proxy se coloca entre el usuario y el sitio y se queda el token al pasar, que es adversary-in-the-middle. O el token se filtra en una URL, en una cabecera de referencia, en un registro o en una página de error.
Qué sale mal
Esta es la técnica que les quitó valor en silencio a los segundos factores tal y como se despliegan habitualmente. La autenticación multifactor protege el momento del inicio de sesión. Una sesión emitida después de ese momento es una credencial de un solo factor durante toda su vida, así que un atacante que la capture se ha saltado el segundo factor sin llegar a atacarlo.
Los fallos que informamos son vulgares y constantes. Sesiones que no se rotan al iniciar sesión, lo que permite la fijación. Sesiones que sobreviven a un cambio de contraseña, con lo que la subsanación de la víctima no hace nada. Caducidades largas o deslizantes sin límite absoluto. Ninguna revocación en el servidor, cosa habitual con los tokens sin estado, con lo que cerrar sesión es un gesto del lado del cliente. Cookies sin HttpOnly, sin Secure o sin un valor adecuado de SameSite. Y ninguna ligadura entre la sesión y alguna propiedad del cliente, de forma que un token reproducido desde otro país y otro dispositivo se acepta sin más.
Dónde aparece esto en una auditoría
Cogemos una sesión válida de un navegador, la reproducimos desde otra máquina y otra red, y registramos si la aplicación se da cuenta. Después cambiamos la contraseña, cerramos sesión y volvemos a reproducirla, que es lo que le dice al cliente si su respuesta a incidentes terminaría de verdad con una intrusión. El hallazgo declara el token, su vida, sus marcas, el comportamiento de revocación observado y qué consiguió la reproducción. Esto forma parte de cómo probamos el manejo de sesiones de punta a punta.