Stockage local ou cookies

Question

Je veux réduire les temps de chargement de mes sites web en déplaçant tous les cookies dans le stockage local puisqu'ils semblent avoir la même fonctionnalité. Y a-t-il des avantages ou des inconvénients (notamment en termes de performances) à utiliser le stockage local pour remplacer la fonctionnalité des cookies, hormis les problèmes de compatibilité évidents ?

Answer 1

Les cookies et le stockage local ont des objectifs différents. Les cookies servent principalement à lire côté serveur Le stockage local ne peut être lu que par le côté client . La question est donc la suivante : dans votre application, qui a besoin de ces données - le client ou le serveur ?

S'il s'agit de votre client (votre JavaScript), alors il faut changer. Vous gaspillez de la bande passante en envoyant toutes les données dans chaque en-tête HTTP.

S'il s'agit de votre serveur, le stockage local n'est pas si utile car vous devez transmettre les données d'une manière ou d'une autre (avec Ajax ou des champs de formulaire cachés ou autre). Cela peut convenir si le serveur n'a besoin que d'un petit sous-ensemble des données totales pour chaque requête.

Dans tous les cas, vous devrez laisser votre cookie de session en tant que cookie.

Conformément à la différence technique, et aussi à ma compréhension :

1. En plus d'être une vieille méthode de sauvegarde des données, les cookies vous donnent une limite de 4096 octets (4095, en fait) - c'est par cookie. Le stockage local est aussi grand que 5MB par domaine - Question sur le SO le mentionne également.

2. localStorage est une mise en œuvre de la Storage Interface. Elle stocke les données avec pas de date d'expiration et se fait blanchir seulement par le biais de JavaScript, ou en effaçant le cache du navigateur / les données stockées localement - contrairement à l'expiration des cookies.

Answer 2

Dans le contexte des JWTs Stormpath a rédigé un article très utile décrivant les différentes manières de les stocker et les (dés)avantages de chaque méthode.

Il présente également un bref aperçu des attaques XSS et CSRF et de la manière dont vous pouvez les combattre.

J'ai joint quelques extraits de l'article ci-dessous, au cas où l'article serait mis hors ligne/le site ne fonctionnerait plus.

Stockage local

Problèmes :

Le stockage Web (localStorage/sessionStorage) est accessible par JavaScript sur le même domaine. Cela signifie que tout JavaScript exécuté sur votre site aura accès au stockage Web et, de ce fait, peut être vulnérable aux attaques de type cross-site scripting (XSS). En résumé, XSS est un type de vulnérabilité dans lequel un attaquant peut injecter du JavaScript qui s'exécutera sur votre page. Les attaques XSS de base tentent d'injecter du JavaScript par le biais d'entrées de formulaire, où l'attaquant place alert('You are Hacked') ; dans un formulaire pour voir s'il est exécuté par le navigateur et peut être vu par d'autres utilisateurs.

La prévention :

Pour éviter les XSS, la réponse courante consiste à échapper et à coder toutes les données non fiables. Mais c'est loin d'être le cas. En 2015, les applications web modernes utilisent du JavaScript hébergé sur des CDN ou des infrastructures externes. Les applications web modernes incluent des bibliothèques JavaScript tierces pour les tests A/B, l'analyse des entonnoirs/du marché et les publicités. Nous utilisons des gestionnaires de paquets comme Bower pour importer le code d'autres personnes dans nos applications.

Que faire si un seul des scripts que vous utilisez est compromis ? Malveillant JavaScript malveillant peut être intégré à la page, et le stockage Web est compromis. Ces types d'attaques XSS peuvent obtenir le stockage Web de toute personne qui visite votre site, à leur insu. C'est probablement la raison pour laquelle de nombreuses organisations conseillent de ne rien stocker de valeur ou de ne pas faire confiance toute information dans le stockage web. Cela inclut les identifiants de session et les jetons.

En tant que mécanisme de stockage, le stockage sur le Web n'impose pas d'obligation de sécurité. pendant le transfert. Quiconque lit Web Storage et l'utilise doit faire preuve de diligence raisonnable pour s'assurer qu'ils envoient toujours le JWT sur HTTPS et jamais par HTTP.

Cookies

Problèmes :

Les cookies, lorsqu'ils sont utilisés avec l'indicateur de cookie HttpOnly, ne sont pas accessibles par JavaScript et sont à l'abri de XSS. Vous pouvez également définir l'indicateur Secure cookie pour garantir que le cookie est uniquement envoyé via HTTPS. C'est l'une des principales raisons pour lesquelles les cookies ont été utilisés dans le passé pour stocker des jetons ou des données de session. Les développeurs modernes hésitent à utiliser les cookies car ils exigent traditionnellement que l'état soit stocké sur le serveur, ce qui enfreint les meilleures pratiques RESTful. Les cookies en tant que mécanisme de stockage n'exigent pas que l'état soit stocké sur le serveur si vous stockez un JWT dans le cookie. En effet, le JWT encapsule tout ce dont le serveur a besoin pour répondre à la demande.

Cependant, les cookies sont vulnérables à un autre type d'attaque : le cross-site request forgery (CSRF). Une attaque CSRF est un type d'attaque qui se produit lorsqu'un site web, un courrier électronique ou un blog malveillant fait en sorte que le navigateur d'un utilisateur navigateur d'un utilisateur à effectuer une action non désirée sur un site de confiance sur lequel l'utilisateur est actuellement authentifié. Il s'agit d'une exploitation de la manière dont le navigateur gère les cookies. Un cookie ne peut être envoyé que vers les domaines dans lesquels il est autorisé. Par défaut, il s'agit du domaine qui a initialement le cookie. Le cookie sera envoyé pour une requête indépendamment du fait que si vous êtes sur galaxies.com ou hahagonnahackyou.com.

La prévention :

Les navigateurs modernes prennent en charge l'option SameSite drapeau en plus de HttpOnly y Secure . L'objectif de ce drapeau est d'empêcher la transmission du cookie dans les requêtes intersites, ce qui permet d'éviter de nombreux types d'attaques CSRF.

Pour les navigateurs qui ne prennent pas en charge SameSite Il est possible d'éviter le CSRF en utilisant des modèles de jetons synchronisés. Ce semble compliqué, mais tous les frameworks web modernes prennent en charge cette pour cela.

Par exemple, AngularJS a une solution pour valider que le cookie est accessible uniquement par votre domaine. Tout droit sorti de la documentation d'AngularJS :

Lors de l'exécution de requêtes XHR, le service $http lit un jeton dans un cookie cookie (par défaut, XSRF-TOKEN) et le définit comme un en-tête HTTP (X-XSRF-TOKEN). Étant donné que seul le JavaScript exécuté sur votre domaine peut lire le cookie, votre serveur peut être assuré que le XHR provient de JavaScript s'exécutant sur votre domaine. Vous pouvez rendre cette protection CSRF sans état en incluant un xsrfToken Réclamation JWT :

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

En utilisant la protection CSRF de votre framework d'application web, les cookies sont très solides solides pour stocker un JWT. Il est également possible d'éviter partiellement le CSRF en vérifiant les en-têtes HTTP Referer et Origin de votre API. CSRF auront des en-têtes Referer et Origin qui ne sont pas liés à votre application. votre application.

L'article complet se trouve ici : https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Ils proposent également un article utile sur la meilleure façon de concevoir et de mettre en œuvre les JWT, en ce qui concerne la structure du jeton lui-même : https://stormpath.com/blog/jwt-the-right-way/

Answer 3

Avec localStorage Les applications web peuvent stocker des données localement dans le navigateur de l'utilisateur. Avant HTML5, les données des applications devaient être stockées dans des cookies, inclus dans chaque requête du serveur. De grandes quantités de données peuvent être stockées localement, sans affecter les performances du site web. Bien que localStorage est plus moderne, les deux techniques présentent des avantages et des inconvénients.

Cookies

Pour

• Support historique (il existe depuis toujours)
• Données persistantes
• Dates d'expiration
• Les cookies peuvent être marqués comme HTTPOnly, ce qui peut limiter les attaques XSS sur le navigateur de l'utilisateur pendant sa session (mais ne garantit pas une immunité totale aux attaques XSS).

Cons

• Chaque domaine stocke tous ses cookies dans une seule chaîne, ce qui peut rendre le l'analyse des données
• Les données ne sont pas cryptées, ce qui devient un problème car... ... bien que de petite taille, les cookies sont envoyés avec chaque requête HTTP Taille limitée (4KB)

Stockage local

Pour

• Prise en charge par la plupart des navigateurs modernes
• Les données persistantes qui sont stockées directement dans le navigateur.
• Les règles de même origine s'appliquent aux données de stockage local
• N'est pas envoyé avec chaque requête HTTP
• ~5MB de stockage par domaine (soit 5120KB)

Cons

• Non supporté par quoi que ce soit avant : IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Si le serveur a besoin d'informations stockées sur le client, vous avez volontairement l'envoyer.

localStorage est presque identique à celle de la session. Leurs méthodes sont à peu près identiques, ce qui fait que le passage de la version session à la version localStorage est vraiment un jeu d'enfant. Toutefois, si les données stockées sont vraiment cruciales pour votre application, vous utiliserez probablement les cookies comme solution de secours au cas où localStorage n'est pas disponible. Si vous souhaitez vérifier la prise en charge par votre navigateur de localStorage il suffit d'exécuter ce 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
}

"Les valeurs de localStorage sur les pages sécurisées (SSL) sont isolées" comme quelqu'un l'a remarqué, gardez à l'esprit que localStorage ne sera pas disponible si vous passez du protocole sécurisé 'http' à 'https', où le cookie sera toujours le cookie sera toujours accessible. C'est un point important à connaître important d'en être conscient si vous travaillez avec des protocoles sécurisés.

Answer 4

Cookies :

1. Introduit avant le HTML5.
2. A une date d'expiration.
3. Effacé par JS ou par Clear Browsing Data du navigateur ou après la date d'expiration.
4. Sera envoyé au serveur pour chaque demande.
5. La capacité est de 4KB.
6. Seules les chaînes de caractères peuvent être stockées dans les cookies.
7. Il existe deux types de cookies : persistants et de session.

Stockage local :

1. Introduit avec HTML5.
2. N'a pas de date d'expiration.
3. Effacé par JS ou par Clear Browsing Data du navigateur.
4. Vous pouvez sélectionner le moment où les données doivent être envoyées au serveur.
5. La capacité est de 5MB.
6. Les données sont stockées indéfiniment et doivent être des chaînes de caractères.
7. Il n'y a qu'un seul type.

Answer 5

Principales différences :

Capacité :

• Stockage local : 10MB
• Cookies : 4kb

Support des navigateurs :

• Stockage local : HTML5
• Cookies : HTML4, HTML5

Lieu de stockage :

• Stockage local : Navigateur uniquement
• Cookies : Navigateur et serveur

Envoyer avec demande :

• Stockage local : Oui
• Cookies : Non

Accessed From :

• Stockage local : Toute fenêtre
• Cookies : N'importe quelle fenêtre.

Date d'expiration :

• Stockage local : N'expire jamais, jusqu'à ce que cela soit fait par javascript.
• Cookies : Oui, avoir une date d'expiration.

Note : Utilisez cela, ce qui vous convient.