local storage - online - Protección CSRF con JSON Web Tokens

save token in localstorage

Question

Leí que al usar JWT, no hay necesidad de protegerse contra los ataques CRSF, por ejemplo: " ya que no confía en las cookies, no necesita protegerse contra las solicitudes entre sitios ".

Sin embargo, algo que no entiendo: si almaceno el token en localStorage (como me recomendaron en un tutorial del mismo sitio web ), ¿qué impide que un atacante falsifique una solicitud maliciosa leyendo mi localStorage en lugar de mis cookies?

Como se generó en el lado del servidor, no entiendo cómo podría usar un token para una solicitud de cliente sin que se almacene en algún lugar del cliente.

Answer 1

Al utilizar la autenticación basada en token, debe asociar manualmente el token con la solicitud. Contrariamente a las cookies, los tokens no se configuran automáticamente por el navegador, por lo que no son susceptibles de ataques csrf .

Si bien este enfoque está a salvo de los ataques csrf , es susceptible a los ataques xss .

Una mejora de esfuerzo mínimo sería utilizar el session storage lugar del local storage ya que session storage datos de session storage se eliminan después de que el usuario cierre la pestaña / navegador.

Answer 2

Estrictamente hablando, sí, cualquier cosa almacenada en el almacenamiento local / de sesión (que llamaré Almacenamiento HTML5) podría ser robada en un ataque de scripts entre sitios (XSS). Ver este articulo

Sin embargo, hay muchas partes móviles a considerar.

Primero, hay diferencias sutiles en la forma en que el Almacenamiento HTML5 y las cookies se encuentran en el ámbito con respecto al acceso a JavaScript.

El almacenamiento HTML5 es:

• dividido entre http y https. Un elemento almacenado en http://example.com Almacenamiento de HTML5 no puede ser accedido por JavaScript que se ejecuta en https://example.com .
• dividido entre subdominios. Un elemento almacenado en http://example.com Almacenamiento de HTML5 no puede ser accedido por JavaScript que se ejecuta en http://sub.example.com (sin embargo, puedes hacer algunos tricks para solucionar esto).

Las galletas son más sueltas:

• Una cookie con un dominio example.com irá a http://example.com y https://example.com menos que tenga el atributo secure , en cuyo caso solo se enviará a https .
• Las cookies que no se envíen con un dominio explícito solo se devolverán al dominio exacto que las envió. Si el dominio se define explícitamente como example.com , se enviará tanto a example.com como a sub.example.com . (Esta es la parte más confusa de la "especificación" de la cookie, desafortunadamente, vea este artículo ).
• JavaScript puede leer una cookie si se está ejecutando en una página con un dominio coincidente (y respetando el indicador de cookie secure ) a menos que la cookie tenga el atributo httpOnly , en cuyo caso JavaScript no podrá leerlo.

En segundo lugar, dado que las cookies están marcadas con un dominio, cuando se realiza una solicitud a un servidor, el navegador enviará cookies de todos y solo con un dominio coincidente, independientemente del dominio de la página que originó la solicitud .

La última parte es cómo se realiza un ataque CSRF (la política del mismo origen solo ayuda mucho). La página OWASP en CSRF es un buen recurso para aprender cómo funcionan estos tipos de ataques.

La razón por la que se almacena un token de autenticación en el almacenamiento local y se agrega manualmente a cada solicitud de protección contra CSRF es esa palabra clave: manual. Como el navegador no envía automáticamente el token de autenticación, si visito evil.com y logra enviar un POST http://example.com/delete-my-account , no podrá enviar mi token authn, por lo que la solicitud es ignorada

Con lo anterior en mente, si usar una cookie o almacenamiento HTML5 se convierte en una serie de concesiones:

Almacenar el token de autenticación en el almacenamiento HTML5 significa:

• (-) Riesgo de robo en un ataque XSS.
• (+) Proporciona protección CSRF.
• (-) Debe modificar manualmente cada solicitud que va al servidor, limitándose a las aplicaciones web SPA (por ejemplo, AngularJs).

Por otro lado, si almacena el token authn en una cookie marcada como httpOnly y secure , entonces:

• (+) El token de authn no puede ser robado por XSS.
• (-) Deberá proporcionar la protección CSRF usted mismo. Implementar la protección CSRF es más fácil en algunos marcos que en otros.

Qué opción es mejor depende de tus necesidades.

• ¿Tu token automático protege algo relacionado con el dinero? Probablemente querrá la cookie httpOnly opción secure .
• ¿El nivel de esfuerzo requerido para implementar la protección CSRF no vale los activos que está protegiendo? Entonces el almacenamiento HTML5 podría ser el lugar correcto.