Dónde almacenar JWT en el navegador? Cómo protegerse contra CSRF?

Conozco la autenticación basada en cookies. SSL y HttpOnly flag se pueden aplicar para proteger la autenticación basada en cookies de MITM y XSS. Sin embargo, será necesario aplicar más medidas especiales para protegerlo de la CSRF. Son un poco complicadas. (referencia )

Recientemente, descubrí que JSON Web Token(JWT) es bastante caliente como una solución para la autenticación. Conozco las cosas sobre la codificación, decodificación y verificación de JWT. Sin embargo, no entiendo por qué algunos los sitios web/tutoriales dicen que no necesita protección CSRF si se utiliza JWT. He leído bastante y trato de resumir los problemas a continuación. Solo quiero que alguien pueda proporcionar el panorama general de JWT y aclarar los conceptos que malinterpreté sobre JWT.

  1. Si el JWT se almacena en una cookie, creo que es lo mismo que la autenticación basada en cookies, excepto que el servidor no necesita tener sesiones para verificar la cookie/token. Si no se aplica ninguna medida especial, sigue existiendo el riesgo de que se aplique el marco de referencia. ¿No se almacena JWT en cookie?

  2. Si el JWT se almacena en localStorage / sessionStorage, entonces no hay cookie, por lo que no es necesario proteger contra CRSF. La pregunta es cómo enviar el JWT al servidor. Encontré aquí sugiere usar jQuery para enviar el encabezado JWT por HTTP de las solicitudes ajax. Entonces, ¿solo las solicitudes ajax pueden hacer la autenticación?

  3. Además, encontré uno más blog muestra el uso de "Encabezado de autorización" y "Portador" para enviar el JWT. No entiendo el método del que habla el blog. ¿Podría alguien explicar más sobre "Encabezado de autorización"y " Portador"? ¿Esto hace que el encabezado JWT transmitido por HTTP sea el de TODAS las solicitudes? En caso afirmativo, ¿qué tal CSRF?

Author: MvdD, 2014-11-21
Source

2 answers

Los tokens JWT son populares ya que se utilizan como formato de token predeterminado en nuevos protocolos de autorización y autenticación como OAuth 2.0 y OpenID Connect.

Cuando el token se almacena en una cookie, el navegador lo enviará automáticamente junto con cada solicitud al mismo dominio y esto sigue siendo vulnerable a los ataques CSRF.

La autenticación al portador es uno de los esquemas de autenticación definidos en HTTP. Básicamente significa que YOU pegar el (JWT) en el encabezado HTTP Authorization de una solicitud. El navegador NOT hará esto por usted automáticamente, por lo que no es adecuado para proteger su sitio web. Como el navegador no agrega automáticamente el encabezado a su solicitud, no es vulnerable a un ataque CSRF, que depende de que su información de autenticación se envíe automáticamente al dominio original.

El esquema bearer se usa a menudo para proteger las API web (servicios REST) que se consumen a través de llamadas AJAX o desde dispositivos móviles cliente.

 40
Author: MvdD,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-12-14 05:23:19

Necesitamos almacenar el JWT en el equipo cliente. Si lo almacenamos en un localStorage / sessionStorage entonces puede ser fácilmente agarrado por un ataque XSS. Si lo almacenamos en cookies, un hacker puede usarlo (sin leerlo) en un ataque CSRF y hacerse pasar por el usuario y ponerse en contacto con nuestra API y enviar solicitudes para realizar acciones u obtener información en nombre de un usuario.

Pero hay varias formas de asegurar el JWT en las cookies para que no se roben fácilmente (pero todavía hay algunas avanzadas técnicas para robarlos). Pero si quieres confiar en localStorage / sessionStorage, entonces se puede acceder mediante un simple ataque XSS.

Así que para resolver el problema de CSRF, utilizo Cookies de Doble envío en mi aplicación.

Método de Doble envío de Cookies

  1. Almacene JWT en una cookie HttpOnly y la use en modo seguro para transferir a través de HTTPS.

  2. La mayoría de los ataques CSRF tienen un encabezado de origen o referencia diferente con su host original en sus solicitudes. Tan compruebe si tiene alguno de ellos en el encabezado, ¡vienen de su dominio o no! Si no rechazarlos. Si tanto el origen como el referente no están disponibles en la solicitud, no se preocupe. Puede confiar en el resultado de los resultados de validación de encabezado X-XSRF-TOKEN que explico en el siguiente paso.

  3. Si bien el navegador proporcionará automáticamente sus cookies para el dominio de la solicitud, hay una limitación útil: el código JavaScript que se ejecuta en un sitio web no puede leer el cookies de otros sitios web. Podemos aprovechar esto para crear nuestra solución CSRF. Para evitar ataques CSRF, debemos crear una cookie legible Javascript adicional que se llama: XSRF-TOKEN. Esta cookie debe crearse cuando el usuario ha iniciado sesión y debe contener una cadena aleatoria que no se pueda adivinar. También guardamos este número en el propio JWT como una reclamación privada. Cada vez que la aplicación JavaScript quiera hacer una solicitud, tendrá que leer este token y enviarlo en un encabezado HTTP personalizado. Porque estas operaciones (leer la cookie, configurar el encabezado) solo se pueden realizar en el mismo dominio de la aplicación JavaScript, podemos saber que esto lo está haciendo un usuario real que está utilizando nuestra aplicación JavaScript.

Angular JS hace su vida fácil

Afortunadamente, estoy usando Angular JS en nuestra plataforma y Angular empaqueta el enfoque de token CSRF, lo que nos facilita la implementación. Para cada solicitud que nuestra aplicación Angular hace del servidor, el El servicio Angular $http hará estas cosas automáticamente:

  • Busque una cookie llamada XSRF-TOKEN en el dominio actual.
  • Si se encuentra esa cookie, lee el valor y lo agrega a la solicitud como el encabezado X-XSRF-TOKEN.

Por lo tanto, la implementación del lado del cliente se maneja para usted, automáticamente! Solo necesitamos establecer una cookie llamada XSRF-TOKEN en el dominio actual en el lado del servidor y cuando nuestra API recibió cualquier llamada del cliente, debe verificar el encabezado X-XSRF-TOKEN y compáralo con el XSRF-TOKEN en el JWT. Si coinciden, entonces el usuario es real. De lo contrario, es una solicitud falsa y puedes ignorarla. Este método está inspirado en el método "Double Submit Cookie".

Precaución

En realidad, todavía eres susceptible a XSS, es solo que el atacante no puede robarte el token JWT para su uso posterior, pero aún puede hacer solicitudes en nombre de tus usuarios usando XSS.

Si almacena su JWT en localStorage o si almacena su token XSRF en not HttpOnly cookie, ambos pueden ser agarrados fácilmente por XSS. Incluso su JWT en una cookie HttpOnly puede ser capturado por un ataque XSS avanzado como método XST.

Por lo tanto, además del método de Doble envío de cookies, siempre debe seguir las mejores prácticas contra XSS, incluido el escape de contenido. Esto significa eliminar cualquier código ejecutable que haga que el navegador haga algo que no desea que haga. Por lo general, esto significa eliminar las etiquetas // <![CDATA[ y los atributos HTML que causan que JavaScript ser evaluado.

Lea más aquí:

 82
Author: Iman Sedighi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-09-09 21:15:51