No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Almacenamiento seguro de tokens JWT: Session Storage y cookies HTTP Only

9/13
Recursos

¿Cómo almacenar de manera segura un token JWT?

Muchas personas, al abordar el almacenamiento de tokens JWT, optan por local storage dado su uso extendido en internet y en numerosos tutoriales. Pero, ¿es realmente seguro? En realidad, no existe un método de almacenamiento completamente seguro en la web. Al hablar de seguridad, generalmente nos enfrentamos a vulnerabilidades de Cross-Site Request Forgery (CSRF) y Cross-Site Scripting (XSS). Dependiendo de nuestra elección, estaremos más expuestos a uno u otro tipo de ataque. Reconocer las vulnerabilidades nos permite tomar medidas para incrementar la seguridad. Veamos cómo.

Vulnerabilidades comunes al almacenar tokens

Cookies seguras: Las cookies, cuando son HTTP Only y SameSite, son una gran opción por defecto. Están protegidas contra XSS, pero son vulnerables a CSRF, ya que siempre se envían al servidor. Se requiere una protección adicional para verificar su autenticidad.

Session Storage o Local Storage: Están a salvo de CSRF porque no se envían automáticamente al servidor, pero son vulnerables a XSS. Un atacante podría, mediante código inyectado, leer valores almacenados, especialmente si estamos expuestos a librerías externas de procedencia dudosa.

¿Qué nos sugiere OWASP sobre el almacenamiento seguro?

OWASP recomienda almacenar tokens en Session Storage. A pesar de ser volátil y estar protegido contra CSRF, debemos abordar la protección contra XSS. Una estrategia eficaz es implementar un fingerprint, un identificador único en una cookie que el servidor genera y valida. El servidor espera tanto el valor del token almacenado como el del fingerprint para operar.

En el caso de optar por cookies:

  • Asegúrate de que tu sitio sea HTTPS.
  • Las cookies deben ser HTTP Only para evitar manipulaciones en el frontend.
  • Implementa medidas adicionales de protección CSRF, como el uso de tokens de verificación.

NextAuth: Una opción segura para la gestión de sesiones JWT

NextAuth ofrece un enfoque robusto para el manejo de sesiones y almacenamiento de tokens JWT. Realiza la autenticación en el navegador, mientras el token se crea en el servidor Node.js de Next.js. Utiliza cookies seguras y HTTP Only, lo que significa que el frontend no puede acceder a los secretos.

El cliente nunca tiene acceso al token, y todas las operaciones se realizan a través del servidor, que manejan de manera segura la información. Además, NextAuth proporciona protección CSRF de manera integrada, utilizando principalmente las rutas de inicio y cierre de sesión.

Estrategias avanzadas para aplicaciones sin servidores

El enfoque cambia drásticamente cuando no existe un servidor que gestione las operaciones de almacenamiento y seguridad. En tales escenarios, se recomendaba el uso de estrategias avanzadas. Aunque no se detallan en este texto, comprender a fondo las vulnerabilidades y sus posibles mitigaciones es esencial para las aplicaciones modernas.

Al considerar las mejores prácticas y herramientas disponibles, podemos mejorar la seguridad de nuestras aplicaciones web contra ataques comunes y proteger mejor nuestros tokens JWT y la información confidencial del usuario.

Aportes 2

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

🗃 ¿Dónde guardar tokens JWT?

Recursos

A note on CSRF attack and JWT authentication

Apuntes

  • La mayoría de internet / tutoriales utilizan localStorage

“No hay almacenamiento que sea seguro por sí mismo”

  • Existen dos vulnerabilidades que generalmente son las que más están presentes, están sujetas a ataques en sesiones y la forma en la que la guardemos
    1. Cross-Site Request Forgery (CSRF)
    2. Cross-Site Scripting (XSS)
  • Dependiendo de la opción en la que guardemos la información, estaremos expuestos a uno u a otro tipo de ataque
  • Si reconocemos que vulnerabilidades tiene nuestro almacenamiento, podremos tomar medidas para realizarlas de mejor forma

¿Dónde guardar tokens JWT?

  • Cookie (Secure, HttpOnly, SameSite)

    ✅ XSS

    ⚠️ CSRF

    • Porque cuando las cookies se envían al servidor, este último necesita una seguridad adicional para saber si esa cookie que está llegando con el request la está realizando realmente un usuario o atáquente
  • Session storage

    ✅ CSRF

    ⚠️ XSS

    • Si nuestros atacantes ganan acceso a nuestro código, inyectando código podrían obtener y leer nuestros almacenamientos
    • Estos ataques pueden suceder también mediante NPM y el navegador no tiene ninguna forma de saber si lo que está sucediendo es por parte de nuestro código o de un atacante

Recomendación de OWASP

  1. sessionStorage
    • Es volátil y vulnerable
    • Fingerprint adicional contra proteger Cross-site Scripting (XSS)
      • Se guardaría en una cookie, es una cadena única que nadie más que el servidor puede crear
      • Esta se crearía cuando se inicie la sesión, se guarda en el servidor y se envía junto con el valor del sessionStorage, el servidor debería esperar ambos valores y para realizar alguna acción deberían ser ambos válidos
  2. Cookie
    • Las cookies deben ser seguras
    • lo primordial es tener un servidor con HTTPS
    • Secure + HttpOnly
    • Protección adicional contra Cross-Site Request Forgery (CSRF)
      • Agregamos una protección adicional la cual se pondrá en otra cookie, ambas se enviarían al servidor y estas serán validadas
    • El CSRF ya está bastante soportado por diferentes frameworks y librerías
      • CSRF hace parte de las cosas más básicas de seguridad con manejo de cookies cuando tenemos un servidor
      • Next Auth nos da un CSRF

¿Cómo lo hace Next Auth?

  • Autenticación en el navegador
  • JWT se crea en el servidor y se guarda en una cookie (Secure*, HttpOnly)
  • Todos los request se hacen a través del servidor.
  • CSRF para páginas login y logout

¿Dónde guardar token JWT?

  • 🚩 Localstorage solo se debe usar para fines didácticos.
  • ✅  sessionStore + fingerprint en una cookie para protegerse de XSS.
  • ✅  cookie (https + secure + http only) + una cookie dedicada para protegerse de CSRF.

Consideraciones para el manejo de sesión segura

  • Autenticación del cliente.
  • JWT creado en el servidor y almacenado en una cookie.
  • Los request tienen una validación de origen.
  • CSRF para login y logout.