Pregunta Almacenamiento local frente a cookies


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 y desventajas (especialmente en lo que se refiere al rendimiento) en el uso del almacenamiento local para reemplazar la funcionalidad de las cookies, a excepción de los obvios problemas de compatibilidad?


796
2017-07-10 20:02


origen


Respuestas:


Las cookies y el almacenamiento local tienen diferentes propósitos. Las cookies son principalmente para leer lado del servidor, el almacenamiento local solo puede ser leído por lado del cliente. Entonces, la pregunta es, en su aplicación, ¿quién necesita esta información, el cliente o el servidor?

Si es tu cliente (tu JavaScript), entonces, por supuesto, cambia. Está desperdiciando ancho de banda al enviar todos los datos en cada encabezado HTTP.

Si se trata de 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 solo necesita un pequeño subconjunto del total de datos para cada solicitud.

Sin embargo, querrá dejar su cookie de sesión como una cookie de cualquier manera.

Según la diferencia técnica, y también mi comprensión:

  1. Además de ser una forma antigua de guardar datos, las cookies te dan un límite de 4096 bytes (4095, en realidad) - es por cookie. El almacenamiento local es tan grande como 5 MB por dominio - ASI pregunta también lo menciona

  2. localStorage es una implementación de la Storage Interfaz. Almacena datos con sin fecha de vencimientoy se limpia solamente a través de JavaScript, o borrando la memoria caché del navegador / datos almacenados localmente, a diferencia de la caducidad de cookies.


988
2017-07-10 20:54



En el contexto de los JWT, Stormpath ha escrito un artículo bastante útil que describe las posibles formas de almacenarlos y las (des) ventajas de cada método.

También tiene una breve descripción general de los ataques XSS y CSRF, y cómo puede combatirlos.

He adjuntado algunos fragmentos del artículo a continuación, en caso de que su artículo sea desconectado / su sitio no funcione.

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 scripts de sitios cruzados (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 es ejecutado por el navegador 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 son de confianza. Pero esto está lejos de la historia completa. En 2015, las aplicaciones web modernas usan 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 gestores de paquetes como Bower para importar el código de otras personas en nuestras aplicaciones.

¿Qué sucede si solo uno de los scripts que usa está en peligro? Malicioso   JavaScript se puede incrustar en la página, y el almacenamiento web es   comprometida. Estos tipos de ataques XSS pueden obtener el almacenamiento web de todos   que visita tu sitio, sin su conocimiento. Esta es probablemente la razón por la cual   grupo de organizaciones aconseja no almacenar nada de valor o confianza   cualquier información en el almacenamiento web. Esto incluye identificadores de sesión y   tokens.

Como mecanismo de almacenamiento, Web Storage no aplica ningún seguro   estándares durante la transferencia. Quien lea Web Storage y lo use debe   hacer su diligencia debida para garantizar que siempre envíen el JWT a través de HTTPS   y nunca HTTP.

Galletas

Problemas:

Las cookies, cuando se usan con la bandera de cookies HttpOnly, no son accesibles a través de JavaScript y son inmunes a XSS. También puede establecer el indicador de cookies seguras para garantizar que la cookie solo se envíe a través de HTTPS. Esta es una de las razones principales por las que las cookies se han aprovechado en el pasado para almacenar tokens o datos de sesión. Los desarrolladores modernos dudan en usar cookies porque tradicionalmente requerían que el estado se almacenara en el servidor, rompiendo así las mejores prácticas REST. Las cookies como mecanismo de almacenamiento no requieren que se almacene estado 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:   la falsificación de solicitudes entre sitios (CSRF). Un ataque CSRF es un tipo de ataque   que ocurre cuando un sitio web malicioso, correo electrónico o blog causa un error   navegador web para realizar una acción no deseada en un sitio confiable en el que   el usuario está autenticado actualmente. Este es un exploit de cómo el   navegador maneja las cookies. Una cookie solo se puede enviar a los dominios de   lo cual está permitido. Por defecto, este es el dominio que originalmente   establecer la cookie La cookie se enviará para una solicitud independientemente de   ya sea que esté en galaxies.com o hahagonnahackyou.com.

Prevención:

CSRF se puede prevenir mediante el uso de patrones de token sincronizados. Esta   suena complicado, pero todos los marcos web modernos tienen soporte para   esta.

Por ejemplo, AngularJS tiene una solución para validar que la cookie es   accesible solo por su dominio Directamente de documentos AngularJS:

Al realizar solicitudes XHR, el servicio $ http lee un token de un   cookie (de forma predeterminada, XSRF-TOKEN) y lo establece como un encabezado HTTP   (X-XSRF-TOKEN). Como solo el JavaScript que se ejecuta en tu dominio puede   lea la cookie, su servidor puede estar seguro de que el XHR vino de   JavaScript ejecutándose en tu dominio. Usted puede hacer que esta protección CSRF   apátrida al incluir una xsrfToken Reclamo JWT:

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

Aprovechar la protección CSRF de su aplicación web hace que las cookies funcionen   sólido para almacenar un JWT. CSRF también puede ser parcialmente prevenido por   verificando el encabezado de HTTP Referer y Origin desde su API. CSRF   Los ataques tendrán jefes 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 útil artículo 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/


121
2018-04-02 00:23



Con localStorage, las aplicaciones web pueden almacenar datos localmente dentro del navegador del usuario. Antes de HTML5, los datos de la aplicación tenían que almacenarse en cookies, incluidos en cada solicitud del servidor. localStorage es más seguro y se pueden almacenar grandes cantidades de datos localmente, sin afectar el rendimiento del sitio web. A pesar de que localStorage es más moderno, hay algunas ventajas y desventajas para ambas técnicas.

Galletas

Pros

  • Soporte heredado (ha existido por siempre)
  • Datos persistentes
  • Fechas de caducidad

Contras

  • Cada dominio almacena todas sus cookies en una sola cadena, lo que puede hacer analizar datos difíciles
  • Los datos no están encriptados, lo que se convierte en un problema porque ... ... aunque de tamaño pequeño, las cookies se envían con cada solicitud HTTP Tamaño limitado (4KB)
  • La inyección SQL se puede realizar desde una cookie

Almacenamiento local

Pros

  • Soporte por la mayoría de los navegadores modernos
  • Datos persistentes que se almacenan directamente en el navegador
  • Las mismas reglas de origen se aplican a los datos de almacenamiento local
  • No se envía con cada solicitud HTTP
  • ~ 5MB de almacenamiento por dominio (eso es 5120KB)

Contras

  • No soportado por nada antes: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
  • Si el servidor necesita información almacenada del cliente, a propósito tiene para enviarlo

localStorage el uso es casi idéntico al de la sesión uno. Tienen métodos bastante exactos, así que cambiar de sesión a localStorage es realmente un juego de niños. Sin embargo, si los datos almacenados son realmente cruciales para su aplicación, probablemente use cookies como respaldo por si acaso. localStorage no está disponible. Si desea verificar el soporte del navegador para localStorage, todo lo que tienes que hacer es ejecutar este simple script:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

"los valores de localStorage en páginas seguras (SSL) están aislados"   como alguien notó, tenga en cuenta que localStorage no será   disponible si cambia de protocolo seguro "http" a "https", donde   la cookie seguirá siendo accesible. Esto es algo importante para   tenga en cuenta si trabaja con protocolos seguros.


55
2018-04-01 02:50



Bueno, la velocidad de almacenamiento local depende en gran medida del navegador que esté utilizando el cliente, así como del sistema operativo. Chrome o Safari en un Mac podrían ser mucho más rápidos que Firefox en una PC, especialmente con las nuevas API. Como siempre, la prueba es tu amiga (no pude encontrar ningún punto de referencia).

Realmente no veo una gran diferencia en las cookies frente al almacenamiento local. Además, debería estar más preocupado por los problemas de compatibilidad: no todos los navegadores han comenzado a admitir las nuevas API de HTML5, por lo que las cookies serían su mejor apuesta por la velocidad y la compatibilidad.


6
2017-07-10 20:13



El almacenamiento local puede almacenar hasta 10mb de datos fuera de línea, mientras que la sesión puede almacenar hasta 5 mb de datos. Pero las cookies pueden almacenar solo datos de 4kb en formato de texto.


6
2017-08-05 09:04



También vale la pena mencionar que localStorageno se puede usar cuando los usuarios navegan en modo "privado" en algunas versiones de Safari móvil.

Citado de MDN (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage)

Nota: a partir de iOS 5.1, Safari Mobile almacena datos locales de almacenamiento en   la carpeta de caché, que está sujeta a limpieza ocasional, en el   del sistema operativo, generalmente si el espacio es corto. Privado de Safari Mobile   El modo de navegación también evita escribir en localStorage por completo.


2
2017-11-21 22:16