El secuestro de sesión se produce cuando un atacante roba o suplanta el identificador de sesión válido de un usuario para obtener acceso no autorizado a las aplicaciones web. Esto puede ocurrir a través de diversos medios, como XSS, sniffing de red o tokens de sesión predecibles. La prevención implica una gestión segura de las sesiones, el uso de HTTPS y la implementación de políticas de tiempo de espera de sesión adecuadas.
Después de que un usuario inicia sesión, el servidor emite un identificador de sesión, normalmente almacenado en una cookie o un token, que sustituye al inicio de sesión en cada solicitud posterior. El secuestro de sesión (session hijacking) es cualquier técnica que permite a un atacante obtener o reproducir ese identificador y usarlo para actuar como el usuario, sin llegar a conocer nunca la contraseña. El robo puede ocurrir de varias formas: cross-site scripting o un script de terceros malicioso que lee la cookie, esnifado de red de tráfico sin cifrar, malware en el dispositivo o adivinar tokens débiles y predecibles. Una vez que el atacante reproduce un ID de sesión válido, la aplicación trata sus solicitudes como las del usuario genuino hasta que la sesión caduca o se revoca.
Una sesión robada concede acceso autenticado inmediato, así que evita por completo el inicio de sesión, incluida la autenticación multifactor que solo se comprobó al entrar. Esta es la esencia de un ataque pass-the-cookie: con una cookie de sesión válida, el atacante a menudo no necesita ni contraseña ni un segundo factor. Según la cuenta, puede leer datos privados, hacer compras, mover fondos o cambiar la configuración para dejar fuera al usuario real. Como las solicitudes llevan una sesión legítima, le parecen normales al servidor, así que la detección suele depender de señales más sutiles, como un cambio repentino de dispositivo o ubicación, en lugar de un fallo evidente.
Envía las cookies de sesión solo por HTTPS, márcalas como HttpOnly para que el JavaScript del lado del cliente no pueda leerlas y establece el atributo SameSite para limitar el envío entre sitios. Usa tokens largos y aleatorios, rótalos cuando cambien los privilegios y aplica tiempos de espera sensatos y revocación del lado del servidor. Como una vía de robo común es un script de terceros malicioso o comprometido que lee cookies o tokens en el navegador, controlar el código del lado del cliente importa: cside enruta los scripts de terceros a través de un método Script, analiza la carga útil y puede bloquear en tiempo real un script que intente exfiltrar datos de sesión, manteniendo un registro forense. Detectar un desajuste de dispositivo en una sesión reutilizada también puede señalar un token secuestrado.
Es un secuestro de sesión que usa una cookie de sesión robada. Como la cookie ya representa una sesión autenticada, un atacante que la obtenga puede importarla en su propio navegador y conseguir acceso sin la contraseña ni un segundo factor. Es una forma preferida de saltarse la autenticación multifactor a posteriori.
No. HttpOnly impide que el JavaScript del lado del cliente, incluidas las cargas útiles de XSS, lea una cookie, lo que cierra una vía de robo importante. Pero las sesiones todavía pueden secuestrarse mediante esnifado de red, malware en el dispositivo o tokens predecibles. Es una capa importante, que funciona mejor combinada con HTTPS, SameSite, una generación de tokens robusta y tiempos de espera.
We answer client-side security questions every day. Bring yours.