Almacenamiento local frente a cookies [cerrado]
Quiero reducir los tiempos de carga en mis sitios web moviendo todas las cookies al almacenamiento local, ya que parecen tener la misma funcionalidad. ¿Existen ventajas o desventajas (especialmente en cuanto al rendimiento) en el uso del almacenamiento local para reemplazar la funcionalidad de las cookies, excepto por los problemas obvios de compatibilidad?
Las cookies y el almacenamiento local tienen diferentes propósitos. Las cookies son principalmente para lectura en el lado del servidor , el almacenamiento local solo puede ser leído por el lado del cliente . Entonces la pregunta es, en su aplicación, ¿quién necesita estos datos: el cliente o el servidor?
Si es su cliente (su JavaScript), entonces cambie. Estás desperdiciando ancho de banda al enviar todos los datos en cada encabezado HTTP.
Si es su servidor, el almacenamiento local no es tan útil porque tendría que reenviar los datos de alguna manera (con Ajax o campos de formulario ocultos o algo así). Esto podría estar bien si el servidor sólo necesita un pequeño subconjunto de los datos totales para cada solicitud.
Sin embargo, querrás dejar tu cookie de sesión como una cookie de cualquier manera.
Según la diferencia técnica, y también según tengo entendido:
Además de ser una forma antigua de guardar datos, las cookies le dan un límite de 4096 bytes (4095, en realidad), es por cookie. El almacenamiento local tiene un tamaño de hasta 10 MB por dominio ; esta pregunta de Stack Overflow también lo menciona.
localStoragees una implementación de laStorageinterfaz. Almacena datos sin fecha de vencimiento y se borra solo a través de JavaScript o borrando la caché del navegador/datos almacenados localmente, a diferencia del vencimiento de las cookies.
En el contexto de los JWT , Stormpath ha escrito un artículo bastante útil que describe posibles formas de almacenarlos y las (des)ventajas relacionadas con cada método.
También tiene una breve descripción general de los ataques XSS y CSRF, y cómo combatirlos.
Adjunté algunos fragmentos breves del artículo a continuación, en caso de que su artículo se desconecte o su sitio se caiga.
Almacenamiento local
Problemas:
Se puede acceder al almacenamiento web (localStorage/sessionStorage) a través de JavaScript en el mismo dominio. Esto significa que cualquier JavaScript que se ejecute en su sitio tendrá acceso al almacenamiento web y, debido a esto, puede ser vulnerable a ataques de secuencias de comandos entre sitios (XSS). XSS en pocas palabras es un tipo de vulnerabilidad donde un atacante puede inyectar JavaScript que se ejecutará en su página. Los ataques XSS básicos intentan inyectar JavaScript a través de entradas de formulario, donde el atacante pone alerta('Estás pirateado'); en un formulario para ver si el navegador lo ejecuta y puede ser visto por otros usuarios.
Prevención:
Para evitar XSS, la respuesta común es escapar y codificar todos los datos que no sean de confianza. Pero esto está lejos de ser la historia completa. En 2015, las aplicaciones web modernas utilizan JavaScript alojado en CDN o infraestructura externa. Las aplicaciones web modernas incluyen bibliotecas de JavaScript de terceros para pruebas A/B, análisis de embudo/mercado y anuncios. Usamos administradores de paquetes como Bower para importar el código de otras personas a nuestras aplicaciones.
¿Qué pasa si sólo uno de los scripts que utiliza está comprometido? Se puede incrustar JavaScript malicioso en la página y el almacenamiento web se ve comprometido. Estos tipos de ataques XSS pueden afectar el almacenamiento web de todos los que visitan su sitio, sin su conocimiento. Probablemente esta sea la razón por la que muchas organizaciones recomiendan no almacenar nada de valor ni confiar en ninguna información en el almacenamiento web. Esto incluye identificadores de sesión y tokens.
Como mecanismo de almacenamiento, Web Storage no aplica ningún estándar seguro durante la transferencia. Quien lea Web Storage y lo utilice debe hacer su debida diligencia para asegurarse de enviar siempre el JWT a través de HTTPS y nunca de HTTP.
Galletas
Problemas:
Las cookies, cuando se utilizan con el indicador de cookies HttpOnly, no son accesibles a través de JavaScript y son inmunes a XSS. También puede configurar el indicador de cookie segura para garantizar que la cookie solo se envíe a través de HTTPS. Esta es una de las principales razones por las que las cookies se han aprovechado en el pasado para almacenar tokens o datos de sesión. Los desarrolladores modernos dudan en utilizar cookies porque tradicionalmente requerían que el estado se almacenara en el servidor, infringiendo así las mejores prácticas de RESTful. Las cookies como mecanismo de almacenamiento no requieren que el estado se almacene en el servidor si está almacenando un JWT en la cookie. Esto se debe a que JWT encapsula todo lo que el servidor necesita para atender la solicitud.
Sin embargo, las cookies son vulnerables a un tipo diferente de ataque: falsificación de solicitudes entre sitios (CSRF). Un ataque CSRF es un tipo de ataque que ocurre cuando un sitio web, correo electrónico o blog malicioso hace que el navegador web de un usuario realice una acción no deseada en un sitio confiable en el que el usuario está actualmente autenticado. Esta es una explotación de cómo el navegador maneja las cookies. Una cookie sólo puede enviarse a los dominios en los que está permitida. De forma predeterminada, este es el dominio que configuró originalmente la cookie. La cookie se enviará para una solicitud independientemente de si se encuentra en galaxies.com o hahagonnahackyou.com.
Prevención:
Los navegadores modernos admiten la
SameSitebandera , además deHttpOnlyySecure. El propósito de este indicador es evitar que la cookie se transmita en solicitudes entre sitios, evitando muchos tipos de ataques CSRF.Para los navegadores que no son compatibles
SameSite, se puede evitar CSRF mediante el uso de patrones de token sincronizados. Esto suena complicado, pero todos los frameworks web modernos lo admiten.Por ejemplo, AngularJS tiene una solución para validar que solo su dominio pueda acceder a la cookie. Directamente de los documentos de AngularJS:
Al realizar solicitudes XHR, el servicio $http lee un token de una cookie (de forma predeterminada, XSRF-TOKEN) y lo establece como un encabezado HTTP (X-XSRF-TOKEN). Dado que solo el JavaScript que se ejecuta en su dominio puede leer la cookie, su servidor puede estar seguro de que el XHR proviene del JavaScript que se ejecuta en su dominio. Puede hacer que esta protección CSRF sea apátrida incluyendo un
xsrfTokenreclamo JWT:{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "[email protected]", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }Aprovechar la protección CSRF del marco de su aplicación web hace que las cookies sean sólidas para almacenar un JWT. CSRF también se puede prevenir parcialmente verificando el encabezado HTTP Referer y Origin de su API. Los ataques CSRF tendrán encabezados Referer y Origin que no están relacionados con su aplicación.
El artículo completo se puede encontrar aquí: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/
También tienen un artículo útil sobre cómo diseñar e implementar mejor los JWT, con respecto a la estructura del token en sí: https://stormpath.com/blog/jwt-the-right-way/
