Get best of the week

Acerca del almacenamiento de tokens JWT en navegadores


El estándar abierto JWT apareció oficialmente en 2015 ( rfc7519 ) prometiendo características interesantes y amplias perspectivas. El almacenamiento adecuado del token de acceso es vital para construir un sistema de autorización y autenticación en la Web moderna, donde los sitios creados con tecnología SPA se están volviendo cada vez más populares.

El almacenamiento incorrecto de tokens conduce a su robo y reutilización por parte de los atacantes.

Entonces, ¿dónde almacenar?


Considere las principales opciones para almacenar el token de acceso JWT en un navegador:

  1. Almacenamiento local / Almacenamiento de sesión : el método no es seguro y es susceptible a ataques como XSS, especialmente si conecta scripts de CDN de terceros (agregar el atributo de integridad no puede garantizar el 100% de seguridad), o no está seguro de si los scripts que conecta no tienen la capacidad de "fusionar" datos de almacenajes a un lado. Además, si el Almacenamiento local está disponible entre pestañas, el Almacenamiento de sesión está disponible en una sola pestaña y abrir un sitio en una pestaña nueva solo provocará una nueva ronda de token / autorización de acceso.
  2. , , fetch . – .
  3. Cookies. «» cookie sessions. Access cookie CSRF. XSS . CSRF Cookie SameSite Strict– , , credentials, CSRF .
    – Access JS httpOnly, Secure .

    Un punto importante es establecer una cookie solo para la API del dominio / ruta de modo que las solicitudes a estadísticas públicas no contengan una sobrecarga en el encabezado.

Cual es el resultado?


Las cookies, cuando se usan correctamente, son la solución adecuada y más segura para almacenar el token de acceso JWT en este momento y deben seguir las siguientes reglas:

  1. Debe instalarse para la API de dominio / ruta para evitar sobrecarga al solicitar archivos estáticos (imágenes públicas / estilos / archivos js).
  2. Tener una bandera segura (para transmisión solo a través de https).
  3. Tener el indicador httpOnly (por incapacidad para acceder desde JavaScript).
  4. El atributo SameSite debe ser estricto para proteger contra ataques CSRF, prohibir la transferencia de cookies si la transición a su API no fue del dominio establecido en la cookie.

En el lado del servidor, también debe configurarse:

  1. Política de seguridad de contenido : restrinja los dominios de confianza para evitar posibles ataques XSS
  2. Cabecera X-Frame-Options para proteger contra ataques de clickjacking.
  3. Protección X-XSS : fuerza el mecanismo de protección incorporado del navegador contra ataques XSS.
  4. X-Content-Type-Options - para proteger contra la sustitución de tipos MIME.

El cumplimiento de estas medidas, junto con la rotación frecuente de tokens de acceso / actualización, debería ayudar a garantizar un alto nivel de seguridad en el sitio.

Limitaciones


A pesar de que el atributo SameSite es compatible con muchos navegadores populares , también hay navegadores que no lo admiten o lo admiten parcialmente (hola IE y Safari para Mac). Para estos casos, necesita un respaldo a los tokens CSRF. En este caso, junto con las solicitudes a la API, también se debe transmitir el token CSRF. El servidor debe generar el token CSRF correcto teniendo en cuenta la huella digital del usuario para minimizar la probabilidad de su sustitución.

More articles:


All Articles