Tokens de sesión - Credenciales temporales de autenticación

Lectura de 2 min aprox.

Un token de sesión es un identificador temporal emitido por el servidor o el cliente para mantener el estado de sesión iniciada de un usuario. HTTP es por naturaleza un protocolo sin estado, en el que cada solicitud constituye una conexión independiente. El token de sesión compensa esta falta de estado y proporciona el mecanismo mediante el cual el servidor puede determinar que «esta solicitud proviene del usuario A que inició sesión antes». En la seguridad de las aplicaciones web, es uno de los elementos más importantes, a la par de la propia autenticación.

La falta de estado de HTTP y la gestión de sesiones

En la época de HTTP/1.0, la web era un protocolo simple para obtener documentos. Estaba diseñado de modo que una solicitud y su respuesta se completaran en un intercambio uno a uno, sin conservar ningún contexto previo ni posterior. Sin embargo, cuando se empezaron a exigir los carritos de compra de los sitios de comercio electrónico y las funciones de inicio de sesión, «conservar el estado» se volvió indispensable. En 1994, Lou Montulli, de Netscape, inventó la cookie, creando un mecanismo que permite al navegador almacenar un identificador emitido por el servidor. Este fue el origen de la gestión de sesiones.

La gestión de sesiones actual se divide a grandes rasgos en dos enfoques: las sesiones del lado del servidor y las sesiones basadas en tokens. La elección entre uno y otro depende de la arquitectura de la aplicación y de sus requisitos de seguridad.

Basado en cookies vs basado en tokens (JWT)

Con las sesiones del lado del servidor, el servidor genera un ID de sesión y almacena los datos de sesión correspondientes en el lado del servidor (en memoria, una base de datos, Redis, etc.). Al cliente solo se le entrega el ID de sesión mediante una cookie, y este envía dicho ID en las solicitudes posteriores. Como el servidor gestiona el estado, las sesiones pueden invalidarse (cierre de sesión, desconexión forzada) de forma instantánea.

Por otra parte, los enfoques basados en tokens, cuyo máximo exponente es el JWT (JSON Web Token), incrustan el estado en el propio token, que incluye la información del usuario y una caducidad. Como el servidor completa la autenticación simplemente verificando la firma del token, no se necesita un almacén de sesiones y la escalabilidad es excelente. Sin embargo, existe un problema fundamental: es difícil invalidar de inmediato un JWT ya emitido. Aunque el usuario cambie su contraseña, un JWT existente puede seguir usándose hasta que caduque. Para mitigar este problema, es habitual combinar un token de acceso de corta duración (alrededor de 15 minutos) con un token de actualización de larga duración.

Ataques contra las sesiones

Los tokens de sesión son un objetivo ideal para los atacantes. El secuestro de sesión es un ataque que roba un token de sesión válido para suplantar al usuario. Una técnica representativa consiste en explotar una vulnerabilidad XSS para leer las cookies desde JavaScript.

La fijación de sesión (Session Fixation) es una técnica en la que el atacante consigue que la víctima utilice un ID de sesión que el propio atacante preparó de antemano. Cuando la víctima inicia sesión con ese ID de sesión, el atacante puede acceder al estado autenticado con ese mismo ID de sesión. Como contramedida, es esencial regenerar el ID de sesión al iniciar sesión correctamente (reemisión de la sesión). Los ataques CSRF también presuponen la existencia de tokens de sesión y están estrechamente relacionados con la gestión de sesiones. Puedes consultar contramedidas concretas en contramedidas contra el secuestro de sesión y en defensas contra el robo de tokens de sesión.

Reforzar la seguridad con los atributos de las cookies

Cuando se gestionan los tokens de sesión con cookies, una configuración adecuada de los atributos es la clave de la seguridad. El atributo Secure restringe el envío de cookies solo a través de conexiones HTTPS y, combinado con el cifrado del canal de comunicación, previene las escuchas. El atributo HttpOnly prohíbe el acceso a las cookies desde JavaScript, evitando el robo de tokens mediante XSS. El atributo SameSite controla el envío de cookies en las solicitudes entre sitios, reduciendo el riesgo de ataques CSRF.

Estos tres atributos a veces se denominan «los tres tesoros sagrados de las cookies de sesión», y la ausencia de uno solo de ellos puede convertirse en un agujero de seguridad. libros prácticos de seguridad web (Amazon) también explican que la configuración de los atributos de las cookies es un asunto fundamental que se expone en primer lugar.

Diseño de la caducidad de los tokens

El diseño de la caducidad es en sí mismo un equilibrio entre seguridad y comodidad. Si es demasiado corta, los usuarios se ven obligados a iniciar sesión de nuevo con frecuencia; si es demasiado larga, el daño en caso de filtración del token se hace mayor. Como pauta general, los servicios de alta seguridad como los bancos establecen entre 15 y 30 minutos, los servicios web típicos establecen entre 1 y 24 horas, y los servicios orientados a la comodidad como las redes sociales establecen desde varias semanas hasta varios meses. La seguridad de las contraseñas del navegador es también un tema importante relacionado con la gestión de sesiones.