problemas de seguridad en el almacenamiento JWT

9

Estoy creando un mecanismo de inicio de sesión JWT para un sitio.

Hay dos opiniones muy opuestas sobre cómo almacenar el JWT. Stormpath jura por las cookies httponly: enlace Auth0 jura por localStorage: enlace

Al principio me puse del lado de Auth0, luego con Stormpath, pero ahora vuelvo a pensar que LocalStorage es el mejor. Los escollos de localStorage es que un ataque xss puede capturar el JWT, el escollo de auth0 es un ataque csrf que puede robar la cookie.

Parece que el desarrollador puede hacer que el método de la cookie sea realmente difícil para el hacker para obtener acceso a través de CSRF, pero no imposible. Sin embargo, si el desarrollador utiliza localStorage y administra su base de código y desinfecta sus entradas, parece que el pirata informático no tiene ninguna entrada, ¿está esto mal?

    
pregunta user2331566 12.01.2017 - 13:41
fuente

3 respuestas

4

El principal argumento para el almacenamiento local parece ser este:

  

es más fácil protegerse contra XSS que proteger contra XSRF

El argumento para eso es que XSS se soluciona supuestamente mediante el saneamiento automático de entradas, mientras que CSRF es difícil de entender.

El segundo punto puede o no ser cierto, pero, como lo indica su fuente, la protección completa contra CSRF es relativamente simple. Si su aplicación es tranquila, es simplemente una cuestión de verificar todas las solicitudes POST para un token CSRF *.

XSS por otro lado no es tan simple. El saneamiento de entrada no es la solución, la codificación de la salida es. Y el problema es que esta codificación depende del contexto. Por ejemplo, se necesita una codificación diferente si se encuentra en un contexto de JavaScript o HTML.

Mientras que algunos marcos proporcionan motores de plantillas con codificación automática, otros no. Y la codificación automática generalmente solo codifica HTML, pero no considera XSS en un contexto de JavaScript. Además de que muchos desarrolladores omiten los motores de plantillas en algunos casos y envían directamente las entradas de los usuarios, diría que XSS es más difícil de defender que CSRF.

* Esto está un poco simplificado, y hay otras cosas que considerar. La inyección de HTML, por ejemplo, puede perder tokens CSRF, y la aplicación puede usar solicitudes GET para cambiar el estado del servidor.

Conclusión

No estaría de acuerdo en que XSS es más fácil de defender que CSRF. Como este es el principal argumento para el almacenamiento local, me gustaría utilizar el enfoque de cookies. Proporciona una pequeña mitigación para XSS y también tiene el beneficio adicional de garantizar que los datos relevantes solo se envíen a través de HTTPS (a través del atributo de cookie segura).

    
respondido por el tim 12.01.2017 - 13:59
fuente
2

En mi experiencia como desarrollador y evaluador de pruebas, diría que probablemente sea más fácil trabajar con un marco de desarrollo web que tenga una protección integrada contra CSRF que tener a los desarrolladores correctamente protegidos contra XSS. Esto sugeriría la solución de Stormpath.

Es probable que quieras protegerte de ambos ataques de todos modos.

    
respondido por el Colin Cassidy 12.01.2017 - 13:51
fuente
0

Probablemente el uso de una combinación de ambos sea más seguro porque cada tienda lo protege de una forma de ataque (XSS o CSRF). Aquí hay un buen artículo sobre el mismo:

enlace

    
respondido por el amit_saxena 15.10.2018 - 14:21
fuente

Lea otras preguntas en las etiquetas