Tema 10
Autenticar al usuario es solo el primer paso. Luego la aplicación necesita recordar quién es en cada solicitud posterior. Esa continuidad se construye con sesiones, cookies o tokens, y si se gestiona mal puede abrir la puerta a secuestro de cuenta, fijación de sesión o abuso de sesiones olvidadas.
HTTP es un protocolo sin estado. Eso significa que cada solicitud es independiente y, por sí sola, no recuerda quién hizo la anterior. Para que una aplicación web pueda mantener a un usuario autenticado entre una página y otra, necesita construir un mecanismo adicional de continuidad.
Esa continuidad suele apoyarse en sesiones, cookies o tokens. Son elementos fundamentales para la experiencia del usuario, pero también uno de los puntos más sensibles de la seguridad web. Si un atacante logra robar, fijar, reutilizar o abusar de ese estado, puede actuar como el usuario sin necesidad de volver a autenticarse.
Por eso el problema de seguridad ya no es solo proteger la contraseña, sino proteger la identidad una vez que la sesión está activa.
Una sesión es el mecanismo por el cual la aplicación mantiene contexto entre solicitudes separadas. Luego del login, el sistema necesita reconocer que la próxima petición también pertenece al mismo usuario autenticado.
En términos prácticos, la sesión representa la continuidad del estado de autenticación. Sin ella, el usuario tendría que volver a identificarse en cada interacción.
Existen varias formas de implementar esa continuidad:
Cada modelo tiene ventajas y riesgos, pero todos comparten una exigencia común: proteger el valor que representa la identidad activa.
Las cookies son pequeños datos que el servidor envía al navegador para que este los reenvíe en solicitudes futuras al mismo dominio o contexto permitido. Su uso en autenticación es extremadamente común.
Cuando una cookie contiene o referencia una sesión autenticada, pasa a ser un objetivo muy valioso. Si se filtra o es reutilizada por un atacante, la cuenta puede quedar comprometida sin tocar la contraseña.
La seguridad de la cookie depende en gran medida de cómo se configura.
| Atributo | Función | Impacto en seguridad |
|---|---|---|
| HttpOnly | Impide acceso desde JavaScript | Reduce robo directo por ciertos escenarios de XSS |
| Secure | Restringe envío a HTTPS | Evita exposición en tráfico no cifrado |
| SameSite | Controla envío cross-site | Ayuda a mitigar CSRF |
| Domain y Path | Definen alcance | Reducen exposición innecesaria dentro del sitio |
| Expires o Max-Age | Determinan duración | Influyen en cuánto tiempo puede reutilizarse |
Si el sistema usa un identificador de sesión, este debe ser suficientemente aleatorio e impredecible. Si puede adivinarse o generarse con un patrón débil, un atacante podría intentar anticiparlo y reutilizarlo.
La sesión no debe basarse en valores triviales, secuenciales o derivados de información pública del usuario.
La fijación de sesión ocurre cuando el atacante logra que la víctima use un identificador de sesión conocido o controlado por él. Luego, si la víctima se autentica sobre esa misma sesión, el atacante ya conoce el valor válido y puede intentar reutilizarlo.
Una defensa clásica consiste en regenerar el identificador de sesión después del login y también al cambiar de privilegio o contexto sensible. Así se evita que una sesión previa o inducida siga siendo válida tras la autenticación.
El secuestro de sesión ocurre cuando un atacante obtiene un valor de sesión válido y lo reutiliza para actuar como la víctima. Esto puede pasar por diferentes caminos:
Una vez secuestrada, la sesión puede permitir acceso inmediato sin necesidad de contraseña o MFA.
La duración de una sesión es un punto delicado. Si dura demasiado, un valor robado o una sesión olvidada sigue siendo útil durante más tiempo. Si dura demasiado poco, la usabilidad se vuelve mala. Por eso se suele trabajar con dos ideas:
El equilibrio depende del riesgo de la aplicación y del tipo de acción que protege.
No todas las acciones deberían confiar igual en una sesión antigua. Para operaciones críticas como cambio de contraseña, modificación de datos de recuperación, transferencias o acceso administrativo, conviene reautenticar o pedir una prueba adicional reciente.
Esto reduce impacto de sesiones abiertas en equipos compartidos, robo de sesión y ataques donde la sesión sigue viva, pero ya no representa una intención suficientemente fresca del usuario.
En muchas arquitecturas modernas se usan tokens firmados, como JWT, para transportar identidad y contexto. Su uso puede ser adecuado, pero implica responsabilidades claras:
Un error frecuente es pensar que porque un token está firmado ya no hace falta gestionarlo con cuidado. En realidad, sigue siendo una credencial de acceso.
El lugar donde se guarda el token importa mucho. Distintos mecanismos exponen riesgos distintos. Por ejemplo, almacenamiento accesible desde JavaScript puede verse más afectado por XSS, mientras que cookies automáticas reintroducen preocupaciones de CSRF si no se configuran correctamente.
No existe una respuesta única universal. La decisión debe evaluarse junto con el modelo de amenaza, la arquitectura del frontend y las capas defensivas disponibles.
Un cierre de sesión seguro no debería limitarse a ocultar la interfaz o borrar elementos visuales. Debe invalidar realmente el contexto autenticado o el token asociado, de modo que no pueda seguir reutilizándose.
Esto es importante cuando:
En algunos sistemas, especialmente con tokens del lado cliente, puede existir la tentación de considerar suficiente “olvidar” el token en la interfaz. Eso puede ser insuficiente si el token sigue siendo aceptado por el backend hasta su expiración.
Cuando el riesgo lo requiere, la aplicación debe contar con mecanismos reales de invalidación, revocación o rotación, y no depender solo de que el cliente deje de mostrar el valor.
Muchas aplicaciones permiten múltiples sesiones abiertas en distintos dispositivos o navegadores. Esto es útil para el usuario, pero también amplía la superficie de riesgo. Un diseño maduro suele considerar:
Imaginemos un portal administrativo que permite login con MFA, pero una vez dentro conserva la misma sesión durante días y no invalida otras sesiones al cambiar la contraseña. Si un atacante obtiene una cookie válida mediante equipo comprometido o sesión olvidada, puede seguir accediendo aunque la contraseña ya haya cambiado.
Este ejemplo muestra que autenticación fuerte y gestión de sesión débil pueden anularse entre sí.
Una estrategia madura suele combinar:
La seguridad de sesión es la continuación natural de la autenticación. Si la aplicación autentica bien al usuario, pero luego conserva mal su estado, el valor del login seguro se pierde rápidamente. Proteger sesiones, cookies y tokens es proteger la identidad ya iniciada en el momento donde suele resultar más valiosa para un atacante.
En el próximo tema veremos protección de datos sensibles, cifrado y almacenamiento seguro, para extender la seguridad desde identidades y sesiones hacia la información que la aplicación guarda y procesa.