Frage Lokaler Speicher gegen Cookies


Ich möchte die Ladezeiten auf meinen Websites reduzieren, indem ich alle Cookies in den lokalen Speicher verschiebe, da sie die gleiche Funktionalität zu haben scheinen. Gibt es irgendwelche Vor- und Nachteile (insbesondere hinsichtlich der Leistung) bei der Verwendung von lokalem Speicher, um die Cookie-Funktionalität zu ersetzen, mit Ausnahme der offensichtlichen Kompatibilitätsprobleme?


796
2017-07-10 20:02


Ursprung


Antworten:


Cookies und lokaler Speicher dienen verschiedenen Zwecken. Cookies dienen hauptsächlich zum Lesen serverseitig, lokaler Speicher kann nur von der Client-Seite. Die Frage ist also, wer in Ihrer App diese Daten benötigt - den Client oder den Server?

Wenn es Ihr Client (Ihr JavaScript) ist, dann schalten Sie auf jeden Fall um. Sie verschwenden Bandbreite, indem Sie alle Daten in jedem HTTP-Header senden.

Wenn es Ihr Server ist, ist lokaler Speicher nicht so nützlich, weil Sie die Daten irgendwie weiterleiten müssten (mit Ajax oder versteckten Formularfeldern oder etwas). Dies kann in Ordnung sein, wenn der Server nur eine kleine Teilmenge der Gesamtdaten für jede Anforderung benötigt.

Sie möchten jedoch Ihren Sitzungscookie als Cookie zurücklassen.

Nach dem technischen Unterschied und auch nach meinem Verständnis:

  1. Abgesehen davon, dass Sie eine alte Art der Datenspeicherung sind, geben Ihnen Cookies eine Grenze von 4096 Bytes (4095, tatsächlich) - es pro Cookie. Lokaler Speicher ist so groß wie 5 MB pro Domain - SO Frage erwähnt es auch

  2. localStorage ist eine Implementierung der Storage Schnittstelle. Es speichert Daten mit kein Ablaufdatumund wird gelöscht nur durch JavaScript oder Löschen des Browser-Cache / lokal gespeicherte Daten - im Gegensatz zu Cookie-Ablauf.


988
2017-07-10 20:54



Im Zusammenhang mit JWTsStormpath hat einen ziemlich hilfreichen Artikel verfasst, in dem mögliche Speichermöglichkeiten und die (Vor-) Vorteile jeder Methode beschrieben werden.

Es gibt auch einen kurzen Überblick über XSS- und CSRF-Angriffe und wie Sie sie bekämpfen können.

Ich habe ein paar kurze Ausschnitte aus dem untenstehenden Artikel beigefügt, falls ihr Artikel offline genommen wird / ihre Seite ausfällt.

Lokaler Speicher

Probleme:

Auf den Webspeicher (localStorage / sessionStorage) kann über JavaScript in derselben Domäne zugegriffen werden. Dies bedeutet, dass JavaScript, das auf Ihrer Website ausgeführt wird, Zugriff auf Webspeicher hat und daher anfällig für Cross-Site-Scripting-Angriffe (XSS) sein kann. XSS ist eine Art Schwachstelle, bei der ein Angreifer JavaScript einschleusen kann, das auf Ihrer Seite ausgeführt wird. Grundlegende XSS-Angriffe versuchen, JavaScript über Formulareingaben zu injizieren, bei denen der Angreifer Alarm schlägt ("Sie werden gehackt"); in ein Formular, um festzustellen, ob es vom Browser ausgeführt wird und von anderen Benutzern angezeigt werden kann.

Verhütung:

Um XSS zu verhindern, besteht die übliche Antwort darin, alle nicht vertrauenswürdigen Daten zu entschlüsseln und zu codieren. Aber das ist bei weitem nicht die ganze Geschichte. Im Jahr 2015 verwenden moderne Web-Apps JavaScript, das auf CDNs oder außerhalb der Infrastruktur gehostet wird. Moderne Web-Apps enthalten JavaScript-Bibliotheken von Drittanbietern für A / B-Tests, Trichter- / Marktanalysen und Anzeigen. Wir verwenden Paketmanager wie Bower, um den Code anderer Leute in unsere Apps zu importieren.

Was ist, wenn nur eines der Skripts kompromittiert ist? Bösartig   JavaScript kann auf der Seite eingebettet werden, und Web Storage ist   kompromittiert. Diese Arten von XSS-Angriffen können den Webspeicher von jedem Benutzer erhalten   die Ihre Website ohne ihr Wissen besucht. Dies ist wahrscheinlich, warum a   Viele Organisationen empfehlen, nichts Wertvolles oder Vertrauen zu speichern   jede Information im Webspeicher. Dies umfasst Sitzungskennungen und   Token.

Als Speichermechanismus erzwingt Web Storage keine Sicherheit   Standards während der Übertragung. Wer Webspeicher liest und benutzt, muss   tun Sie ihre gebührende Sorgfalt, um sicherzustellen, dass sie das JWT immer über HTTPS senden   und niemals HTTP.

Kekse

Probleme:

Cookies, die mit dem Cookie-Flag HttpOnly verwendet werden, sind nicht über JavaScript zugänglich und sind immun gegen XSS. Sie können auch das Kennzeichen Sicheres Cookie setzen, um sicherzustellen, dass das Cookie nur über HTTPS gesendet wird. Dies ist einer der Hauptgründe dafür, dass Cookies in der Vergangenheit zum Speichern von Token oder Sitzungsdaten verwendet wurden. Moderne Entwickler zögern, Cookies zu verwenden, da sie traditionell den Zustand auf dem Server speichern müssen, wodurch RESTful Best Practices gebrochen werden. Cookies als Speichermechanismus erfordern nicht, dass der Status auf dem Server gespeichert wird, wenn Sie ein JWT im Cookie speichern. Dies liegt daran, dass das JWT alles kapselt, was der Server benötigt, um die Anfrage zu bedienen.

Cookies sind jedoch anfällig für eine andere Art von Angriffen:   Cross-Site Request Forgery (CSRF). Ein CSRF-Angriff ist eine Art von Angriff   Dies tritt auf, wenn eine bösartige Website, E-Mail oder ein Blog die Ursache eines Benutzers verursacht   Webbrowser, um eine unerwünschte Aktion auf einer vertrauenswürdigen Site auszuführen, auf der   Der Benutzer ist derzeit authentifiziert. Dies ist ein Exploit, wie die   Browser behandelt Cookies. Ein Cookie kann nur an die Domains in gesendet werden   was es erlaubt ist. Standardmäßig ist dies die Domäne, die ursprünglich verwendet wurde   Setze den Cookie. Der Cookie wird unabhängig von einer Anfrage gesendet   ob du auf galaxies.com oder hahagonnahackyou.com bist.

Verhütung:

CSRF kann verhindert werden, indem synchronisierte Token-Muster verwendet werden. Dies   klingt kompliziert, aber alle modernen Web-Frameworks haben Unterstützung für   Dies.

Zum Beispiel hat AngularJS eine Lösung, um zu validieren, dass der Cookie ist   Nur für Ihre Domain zugänglich. Direkt von AngularJS Dokumentation:

Beim Ausführen von XHR-Anfragen liest der $ http-Dienst ein Token von einem   cookie (standardmäßig XSRF-TOKEN) und legt es als HTTP-Header fest   (X-XSRF-TOKEN). Da nur JavaScript, das auf Ihrer Domain läuft, kann   Lesen Sie den Cookie, Ihr Server kann sicher sein, dass das XHR stammt   JavaScript wird in Ihrer Domain ausgeführt. Sie können diesen CSRF-Schutz einrichten   staatenlos, indem a xsrfToken JWT Anspruch:

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

Die Nutzung des CSRF-Schutzes Ihres Web-App-Frameworks sorgt dafür, dass Cookies rocken   Solid zum Speichern eines JWT. CSRF kann auch teilweise verhindert werden   Überprüfen Sie den Header HTTP Referer und Origin von Ihrer API. CSRF   Angriffe haben Referer- und Origin-Header, die nichts damit zu tun haben   Ihre Bewerbung.

Der vollständige Artikel kann hier gefunden werden: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Sie haben auch einen hilfreichen Artikel darüber, wie man JWTs am besten gestaltet und implementiert, in Bezug auf die Struktur des Token selbst: https://stormpath.com/blog/jwt-the-right-way/


121
2018-04-02 00:23



Mit localStorageWebanwendungen können Daten lokal im Browser des Benutzers speichern. Vor HTML5 mussten die Anwendungsdaten in Cookies gespeichert werden, die in jeder Serveranfrage enthalten waren. localStorage ist sicherer und große Datenmengen können lokal gespeichert werden, ohne die Website-Leistung zu beeinträchtigen. Obwohl localStorage ist moderner, es gibt einige Vor- und Nachteile für beide Techniken.

Kekse

Pros

  • Vermächtnisunterstützung (es ist für immer gewesen)
  • Persistente Daten
  • Ablaufdaten

Nachteile

  • Jede Domain speichert alle ihre Cookies in einer einzigen Zeichenfolge, die sie machen kann Analyse von Daten schwierig
  • Die Daten sind unverschlüsselt, was ein Problem wird, weil ... ... obwohl kleine Größe, Cookies werden mit jeder HTTP-Anfrage gesendet Begrenzte Größe (4KB)
  • Die SQL-Injektion kann von einem Cookie aus durchgeführt werden

Lokaler Speicher

Pros

  • Unterstützung durch die meisten modernen Browser
  • Persistente Daten, die direkt im Browser gespeichert werden
  • Für lokale Speicherdaten gelten die gleichen Ursprungsregeln
  • Wird nicht bei jeder HTTP-Anfrage gesendet
  • ~ 5MB Speicher pro Domain (das ist 5120KB)

Nachteile

  • Bisher nicht unterstützt: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
  • Wenn der Server gespeicherte Client-Informationen benötigt, haben Sie absichtlich um es zu senden.

localStorage Nutzung ist fast identisch mit der Sitzung. Sie haben ziemlich genaue Methoden, also von Sitzung zu wechseln localStorage ist wirklich ein Kinderspiel. Wenn gespeicherte Daten jedoch für Ihre Anwendung von entscheidender Bedeutung sind, werden Sie wahrscheinlich Cookies als Sicherheitskopie verwenden localStorage ist nicht verfügbar. Wenn Sie die Browserunterstützung für überprüfen möchten localStorageAlles, was Sie tun müssen, ist dieses einfache Skript auszuführen:

/* 
* 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
}

"localStorage-Werte auf sicheren (SSL) Seiten sind isoliert"   wie jemand bemerkte, dass localStorage nicht sein wird   verfügbar, wenn Sie von 'http' zu 'https' gesichertem Protokoll wechseln, wo   Der Cookie ist weiterhin zugänglich. Das ist wichtig für   Seien Sie sich bewusst, wenn Sie mit sicheren Protokollen arbeiten.


55
2018-04-01 02:50



Nun hängt die lokale Speichergeschwindigkeit stark vom Browser, den der Client verwendet, sowie vom Betriebssystem ab. Chrome oder Safari auf einem Mac könnte viel schneller sein als Firefox auf einem PC, insbesondere mit neueren APIs. Wie immer, Testen ist dein Freund (ich konnte keine Benchmarks finden).

Ich sehe wirklich keinen großen Unterschied zwischen Cookie und lokalem Speicher. Außerdem sollten Sie sich mehr Sorgen um Kompatibilitätsprobleme machen: Nicht alle Browser haben sogar begonnen, die neuen HTML5-APIs zu unterstützen, daher wären Cookies die beste Wahl für Geschwindigkeit und Kompatibilität.


6
2017-07-10 20:13



Der lokale Speicher kann bis zu 10 MB Offline-Daten speichern, während die Sitzung bis zu 5 MB Daten speichern kann. Aber Cookies können nur 4kb Daten im Textformat speichern.


6
2017-08-05 09:04



Es ist auch erwähnenswert, dass localStoragekann nicht verwendet werden, wenn Benutzer in einigen Versionen von Mobile Safari im "privaten" Modus surfen.

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

Hinweis: Ab iOS 5.1 speichert Safari Mobile lokale Speicherdaten in   der Cache - Ordner, der gelegentlich aufgeräumt wird, im   Betriebssystem, typischerweise wenn der Platz knapp ist. Safari Mobile ist privat   Der Browsing-Modus verhindert außerdem, dass vollständig in localStorage geschrieben wird.


2
2017-11-21 22:16