Nuestro team de trabajo ha estado largas horas buscando para darle solución a tu pregunta, te regalamos la solución así que esperamos que te sea de gran apoyo.
Solución:
Esta respuesta se basa en el enfoque sin estado y, por lo tanto, no habla de la gestión de sesiones tradicional.
Ha hecho dos preguntas completamente diferentes:
- Carrito de compras, que está más relacionado con la funcionalidad comercial.
- OAuth 2 y JWT: relacionado con la seguridad y la autenticación
Como usuario de un sitio web de comercio electrónico, esperaría que cualquier artículo que agregue a mi carrito de compras desde mi dispositivo móvil mientras me desplazo a mi lugar de trabajo, esté disponible en el carrito cuando inicie sesión en el sitio web desde mi PC después de llegar a casa. Por lo tanto, los datos del carrito deben guardarse en la base de datos back-end y vincularse a mi cuenta de usuario.
En lo que respecta a la autenticación mediante OAuth 2.0, el token de acceso de JWT y / o el token de actualización deben almacenarse en algún lugar del dispositivo cliente, de modo que una vez que el usuario se autentica al proporcionar las credenciales de inicio de sesión, no necesita proporcionar sus credenciales nuevamente. para navegar por el sitio web. En este contexto, el almacenamiento local del navegador, el almacenamiento de sesiones y las cookies son opciones válidas. Sin embargo, tenga en cuenta que aquí la cookie no está vinculada a ninguna sesión del lado del servidor. En otras palabras, la cookie no almacena ninguna identificación de sesión. La cookie se usa simplemente como un almacenamiento para el token de acceso que se pasa al servidor con cada solicitud http y el servidor luego valida el token usando la firma digital para asegurarse de que no esté alterado y que no haya caducado.
Aunque las tres opciones de almacenamiento para tokens de acceso y / o actualización son populares, las cookies parecen ser la opción más segura cuando se usan de la manera correcta.
Para entender esto mejor, le recomiendo que lea esto y esto junto con la especificación OAuth 2.0.
Actualización el 16 de febrero de 2019
Dije anteriormente que las cookies parecen ser las opciones más seguras. Me gustaría aclarar más el punto aquí.
La razón por la que creo que el navegador localStorage y sessionStorage no proporcionan suficiente seguridad para almacenar los tokens de autenticación son los siguientes:
-
Si se produce XSS, el script malicioso puede leer fácilmente los tokens desde allí y enviarlos a un servidor remoto. Allí, el servidor remoto o el atacante no tendrían ningún problema en hacerse pasar por el usuario víctima.
-
localStorageysessionStorageno se comparten entre subdominios. Entonces, si tenemos dos SPA ejecutándose en diferentes subdominios, no obtendremos la funcionalidad SSO porque el token almacenado por una aplicación no estará disponible para la otra aplicación dentro de la organización. Hay algunas soluciones que utilizaniframe, pero parecen más soluciones provisionales que una buena solución. Y cuando el encabezado de respuestaX-Frame-Optionsse utiliza para evitar ataques de clickjacking coniframe, cualquier solución coniframeestá fuera de discusión.
Sin embargo, estos riesgos pueden mitigarse mediante el uso de una huella digital (como se menciona en la hoja de referencia de OWASP JWT) que, a su vez, requiere una cookie.
La idea de la huella dactilar es generar una secuencia aleatoria criptográficamente fuerte. string de bytes. El Base64 string de lo crudo string luego se almacenará en un HttpOnly, Secure, SameSite cookie con nombre prefix __Secure-. Valores adecuados para dominio y ruta attributes debe utilizarse según los requisitos comerciales. Un hash SHA256 del string también se aprobará en un reclamo de JWT. Por lo tanto, incluso si un ataque XSS envía el token de acceso JWT a un servidor remoto controlado por un atacante, no puede enviar el original. string en cookie y, como resultado, el servidor puede rechazar la solicitud basándose en la ausencia de la cookie. La galleta es HttpOnly no puede ser leído por scripts XSS.
Por lo tanto, incluso cuando usamos localStorage y sessionStorage, tenemos que usar una cookie para asegurarlo. Además de eso, agregamos la restricción de subdominio como se mencionó anteriormente.
Ahora, la única preocupación sobre el uso de una cookie para almacenar JWT es el ataque CSRF. Desde que usamos SameSite cookie, CSRF se mitiga porque las solicitudes entre sitios (AJAX o simplemente a través de hipervínculos) no son posibles. Si el sitio se utiliza en un navegador antiguo o en otros navegadores no tan populares que no admiten SameSite cookie, aún podemos mitigar CSRF mediante el uso adicional de una cookie CSRF con un valor aleatorio criptográficamente fuerte, de modo que cada solicitud AJAX lea el valor de la cookie y agregue el valor de la cookie en un encabezado HTTP personalizado (excepto las solicitudes GET y HEAD que se supone que no deben hacer cualquier modificación estatal). Dado que CSRF no puede leer nada debido a la misma política de origen y se basa en la explotación de métodos HTTP inseguros como POST, PUT y DELETE, esta cookie de CSRF mitigará el riesgo de CSRF. Este enfoque de uso de cookies CSRF es utilizado por todos los marcos de SPA modernos. El enfoque angular se menciona aquí.
Además, dado que la cookie es httpOnly y Secured, El script XSS no puede leerlo. Por lo tanto, XSS también se mitiga.
También puede valer la pena mencionar que XSS y la inyección de scripts se pueden mitigar aún más mediante el uso de content-security-policy encabezado de respuesta.
Otros enfoques de mitigación de CSRF
- Variable de estado (Auth0 lo usa): el cliente generará y pasará con cada solicitud un nonce aleatorio criptográficamente fuerte que el servidor repetirá junto con su respuesta, lo que permitirá al cliente validar el nonce. Se explica en el documento Auth0.
- Siempre revise el encabezado de referencia y acepte solicitudes solo cuando el remitente sea un dominio de confianza. Si el encabezado del remitente está ausente o es un dominio no incluido en la lista blanca, simplemente rechace la solicitud. Cuando se usa SSL / TLS, la referencia suele estar presente. Las páginas de destino (que son en su mayoría informativas y no contienen un formulario de inicio de sesión ni ningún contenido seguro) pueden ser un poco relajadas y permitir solicitudes sin encabezado de referencia.
- El método TRACE HTTP debe bloquearse en el servidor, ya que se puede usar para leer el
httpOnlyGalleta. - Además, establezca el encabezado Strict-Transport-Security: max-age =; includeSubDomains para permitir solo conexiones seguras para evitar que cualquier intermediario sobrescriba las cookies CSRF de un subdominio.
LocalStorage / SessionStorage es vulnerable a los ataques XXS. El token de acceso se puede leer mediante JavaScript.
Las cookies, con banderas httpOnly, seguras y SameSite = estrictas, son más seguras. No se puede acceder al token de acceso y su carga útil mediante JavaScript.
PERO, si hay una vulnerabilidad XSS, el atacante podría enviar solicitudes como usuario autenticado de todos modos porque el script malicioso no necesita leer el valor de la cookie, las cookies podrían ser enviadas por el navegador automáticamente.
Esta declaración es true pero los riesgos son diferentes.
Con las cookies, el token de acceso todavía está oculto, los atacantes solo pueden realizar ataques “en el sitio”. Los scripts maliciosos inyectados en la aplicación web pueden ser limitados o puede que no sea muy fácil cambiar / inyectar más scripts. Es posible que los atacantes deban atacar primero a los usuarios o las aplicaciones web. Estas condiciones limitan la escala del ataque.
Con localStorage, los atacantes pueden leer el token de acceso y realizar ataques de forma remota. Incluso pueden compartir la ficha con otros atacantes y causar daños más graves. Si los atacantes logran inyectar scripts maliciosos en CDN, digamos API de fuentes de Google, los atacantes podrían desviar el token de acceso y las URL de todos los sitios web que usan el CDN incluido y encontrar fácilmente nuevos objetivos. Los sitios web que utilizan localStorage son más fáciles de convertir en objetivos.
Por el bien de los argumentos
Una prueba de penetración puede marcar el uso de localStorage para datos confidenciales como un riesgo.
Si estaba bien que JavaScript leyera el token de acceso de localStorage de un ataque XSS, ¿por qué cree que todos siguen recomendando el indicador httpOnly?
Recomendación de OWASP
No almacene identificadores de sesión en el almacenamiento local, ya que JavaScript siempre puede acceder a los datos. Las cookies pueden mitigar este riesgo utilizando la marca httpOnly.
https://medium.com/@coolgk/localstorage-vs-cookie-for-jwt-access-token-war-in-short-943fb23239ca
Si aceptas, tienes la habilidad dejar una división acerca de qué le añadirías a este artículo.