Almacenamiento local vs cookies

Solución:

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 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á desperdiciando ancho de banda enviando 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 solo necesita un pequeño subconjunto de los datos totales 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 entendimiento:

1. 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 es tan grande como 5 MB por dominio – SO pregunta también lo menciona.

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

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 correspondientes a cada método.

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

Adjunto algunos fragmentos breves del artículo a continuación, en caso de que su artículo se desconecte o su sitio deje de funcionar.

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 en la que 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 envía una alerta (‘Estás pirateado’); en un formulario para ver si lo ejecuta el navegador y otros usuarios pueden verlo.

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 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 mercado / embudo y anuncios. Usamos administradores de paquetes como Bower para importar el código de otras personas a nuestras aplicaciones.

¿Qué pasa si solo uno de los scripts que usa está comprometido? Se puede incrustar JavaScript malicioso en la página y el almacenamiento web se ve comprometido. Estos tipos de ataques XSS pueden obtener el almacenamiento web de todos los que visitan su sitio, sin su conocimiento. Esta es probablemente la razón por la que un grupo de organizaciones aconseja 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 que siempre envía el JWT a través de HTTPS y nunca de HTTP.

Galletas

Problemas:

Las cookies, cuando se utilizan con la marca de cookies HttpOnly, no son accesibles a través de JavaScript y son inmunes a XSS. También puede configurar el indicador de cookies seguras 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 usar cookies porque tradicionalmente requerían que el estado se almacenara en el servidor, rompiendo así las mejores prácticas de REST. 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: la falsificación de solicitudes entre sitios (CSRF). Un ataque CSRF es un tipo de ataque que se produce 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 de confianza en el que el usuario está actualmente autenticado. Se trata de una explotación de la forma en que el navegador maneja las cookies. Una cookie solo se puede enviar a los dominios en los que está permitida. De forma predeterminada, este es el dominio que originalmente configuró la cookie. La cookie se enviará para una solicitud independientemente de si está en galaxies.com o hahagonnahackyou.com.

Prevención:

Los navegadores modernos admiten la SameSite bandera, además de HttpOnly y Secure. El propósito de esta bandera es evitar que la cookie se transmita en solicitudes entre sitios, evitando muchos tipos de ataques CSRF.

Para navegadores que no admiten SameSite, CSRF se puede prevenir mediante el uso de patrones de token sincronizados. Esto suena complicado, pero todos los frameworks web modernos tienen soporte para esto.

Por ejemplo, AngularJS tiene una solución para validar que solo su dominio puede 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 configura como un encabezado HTTP (X-XSRF-TOKEN). Dado que solo JavaScript que se ejecuta en su dominio puede leer la cookie, su servidor puede estar seguro de que el XHR proviene de JavaScript que se ejecuta en su dominio. Puede convertir esta protección CSRF en apátrida si incluye un xsrfToken Reclamación de 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 al verificar el encabezado HTTP Referer y Origin desde 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/

Con localStorage, las aplicaciones web pueden almacenar datos localmente dentro del navegador del usuario. Antes de HTML5, los datos de la aplicación debían almacenarse en cookies, incluidas en cada solicitud del servidor. 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 algunos pros y contras de ambas técnicas.

Galletas

Pros

• Soporte heredado (ha existido desde siempre)
• Datos persistentes
• Fechas de vencimiento

Contras

• Cada dominio almacena todas sus cookies en una sola cadena, lo que puede dificultar el análisis de los datos.
• Los datos no están encriptados, lo que se convierte en un problema porque … … aunque son 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

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

Contras

• No es compatible con 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 del cliente almacenada, debe enviarla a propósito.

localStorage el uso es casi idéntico al de la sesión uno. Tienen métodos bastante exactos, por lo 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 utilizará cookies como respaldo en caso de localStorage no está disponible. Si desea comprobar la compatibilidad del navegador con localStorage, todo lo que tienes que hacer es ejecutar este sencillo 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 estará disponible si cambia del protocolo seguro ‘http’ a ‘https’, donde la cookie seguirá siendo accesible. Es importante tener esto en cuenta si trabaja con protocolos seguros.

---

---

Utiliza Nuestro Buscador