Local Storage vs Cookies

Question

Ich möchte die Ladezeiten meiner Websites reduzieren, indem ich alle Cookies in den lokalen Speicher verschiebe, da sie anscheinend die gleiche Funktionalität haben. Gibt es Vor- / Nachteile (insbesondere in Bezug auf die Leistung), wenn man den lokalen Speicher verwendet, um die Cookie-Funktionalität zu ersetzen, abgesehen von den offensichtlichen Kompatibilitätsproblemen?

Answer 1

Cookies und lokaler Speicher haben unterschiedliche Zwecke. Cookies dienen hauptsächlich dem Lesen auf der Server-Seite, lokaler Speicher kann nur vom Client gelesen werden. Die Frage ist also, wer in Ihrer App diese Daten benötigt - der Client oder der Server?

Wenn es Ihr Client (Ihr JavaScript) ist, dann wechseln Sie ruhig. 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 ähnlichem). Das wäre in Ordnung, wenn der Server nur eine kleine Teilmenge der Gesamtdaten für jede Anfrage benötigt.

Sie sollten Ihren Session-Cookie so oder so als Cookie belassen.

Was den technischen Unterschied und auch mein Verständnis betrifft:

1. Abgesehen davon, dass es eine alte Methode zum Speichern von Daten ist, bietet Cookies ein Limit von 4096 Bytes (genau genommen 4095) - pro Cookie. Lokaler Speicher kann bis zu 5 MB pro Domain groß sein - wie auch in einer SO-Frage erwähnt.

2. localStorage ist eine Implementierung der Storage-Schnittstelle. Es speichert Daten ohne Ablaufdatum und wird nur durch JavaScript oder das Löschen des Browser-Caches / Lokal gespeicherter Daten gelöscht - im Gegensatz zum Ablaufdatum von Cookies.

Answer 2

Im Kontext von JWTs hat Stormpath einen ziemlich hilfreichen Artikel verfasst, in dem mögliche Methoden zur Speicherung erläutert werden und die (Un-)Vorteile jedes einzelnen Verfahrens.

Es gibt auch einen kurzen Überblick über XSS- und CSRF-Angriffe sowie darüber, wie man ihnen entgegenwirken kann.

Im Falle einer Abschaltung des Artikels oder einer Nichtverfügbarkeit der Website habe ich unten einige kurze Auszüge des Artikels angehängt.

Local Storage

Probleme:

Web Storage (localStorage/sessionStorage) ist über JavaScript auf der gleichen Domain zugänglich. Das bedeutet, dass jedes auf Ihrer Website ausgeführte JavaScript Zugriff auf den Web-Speicher hat und dadurch anfällig für Cross-Site-Scripting (XSS)-Angriffe ist. XSS ist im Grunde genommen eine Art von Schwachstelle, bei der ein Angreifer JavaScript injizieren kann, das auf Ihrer Seite ausgeführt wird. Grundlegende XSS-Angriffe versuchen, JavaScript über Formulareingaben einzuschleusen, wobei der Angreifer versucht, alert('Du wurdest gehackt'); in ein Formular einzufügen, um zu sehen, ob es vom Browser ausgeführt und von anderen Benutzern angesehen werden kann.

Vorbeugung:

Zur Verhinderung von XSS wird normalerweise empfohlen, alle nicht vertrauenswürdigen Daten zu escapen und zu kodieren. Das ist jedoch bei weitem nicht die ganze Geschichte. Moderne Webanwendungen verwenden 2015 JavaScript, das auf CDNs oder außerhalb der Infrastruktur gehostet wird. Moderne Webanwendungen nutzen JavaScript-Bibliotheken von Drittanbietern für A/B-Tests, Funnel-Marktanalysen und Werbung. Wir verwenden Paketmanager wie Bower, um den Code anderer Leute in unsere Anwendungen zu importieren.

Was ist, wenn nur eines der von Ihnen verwendeten Skripte kompromittiert ist? Bösartiges JavaScript kann auf der Seite eingebettet werden, und der Web-Speicher ist kompromittiert. Diese Art von XSS-Angriffen kann den Web-Speicher aller Besucher Ihrer Website ohne deren Wissen erhalten. Das ist wahrscheinlich der Grund, warum viele Organisationen davon abraten, etwas Wertvolles zu speichern oder irgendwelche Informationen im Web-Speicher zu vertrauen. Dazu gehören Sitzungsidentifikatoren und Tokens.

Als Speichermechanismus erzwingt der Web-Speicher keine sicheren Standards während der Übertragung. Jeder, der den Web-Speicher liest und verwendet, muss seine Sorgfalt walten lassen, um sicherzustellen, dass das JWT immer über HTTPS gesendet wird und niemals über HTTP.

Cookies

Probleme:

Cookies, wenn sie mit dem HttpOnly-Cookie-Flag verwendet werden, sind nicht über JavaScript zugänglich und sind immun gegen XSS. Sie können auch das Secure-Cookie-Flag setzen, um zu garantieren, dass das Cookie nur über HTTPS gesendet wird. Dies ist einer der Hauptgründe, warum Cookies in der Vergangenheit verwendet wurden, um Tokens oder Sitzungsdaten zu speichern. Moderne Entwickler zögern jedoch, Cookies zu verwenden, da sie traditionell erforderten, dass der Status auf dem Server gespeichert wird, was die RESTful-Best Practices verletzte. Cookies als Speichermechanismus erfordern keinen Status auf dem Server, wenn Sie ein JWT im Cookie speichern. Dies liegt daran, dass das JWT alles enthält, was der Server benötigt, um die Anfrage zu bedienen.

Allerdings sind Cookies anfällig für einen anderen Angriffstyp: Cross-Site Request Forgery (CSRF). Ein CSRF-Angriff tritt auf, wenn eine bösartige Website, E-Mail oder ein Blog bewirkt, dass der Webbrowser eines Benutzers eine unerwünschte Aktion auf einer vertrauenswürdigen Website ausführt, auf der der Benutzer gerade authentifiziert ist. Dies ist ein Angriff auf die Art und Weise, wie der Browser mit Cookies umgeht. Ein Cookie kann nur an die Domains gesendet werden, für die es zugelassen ist. Standardmäßig handelt es sich dabei um die Domain, die das Cookie ursprünglich gesetzt hat. Das Cookie wird für eine Anfrage gesendet, unabhängig davon, ob Sie sich auf galaxies.com oder hahagonnahackyou.com befinden.

Vorbeugung:

Moderner Browser unterstützen die SameSite Flagge, zusätzlich zu HttpOnly und Secure. Der Zweck dieser Flagge ist es, zu verhindern, dass das Cookie bei Cross-Site-Anfragen übertragen wird, wodurch viele Arten von CSRF-Angriffen verhindert werden.

Für Browser, die SameSite nicht unterstützen, kann CSRF verhindert werden, indem man synchronisierte Tokenmuster verwendet. Das klingt kompliziert, aber alle modernen Web-Frameworks unterstützen das.

Zum Beispiel hat AngularJS eine Lösung, um zu validieren, dass das Cookie nur von Ihrer Domain aus zugänglich ist. Direkt aus den AngularJS-Dokumenten:

Bei XHR-Anfragen liest der $http-Service ein Token aus einem Cookie (standardmäßig XSRF-TOKEN) und setzt es als HTTP-Header (X-XSRF-TOKEN). Da nur JavaScript, das auf Ihrer Domain läuft, das Cookie lesen kann, kann Ihr Server sicher sein, dass die XHR von JavaScript stammt, das auf Ihrer Domain läuft. Sie können diesen CSRF-Schutz zustandslos machen, indem Sie einen xsrfToken JWT-Claim einfügen:

{
  "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 Webanwendungs-Frameworks macht Cookies hervorragend für die Speicherung eines JWT. CSRF kann auch teilweise verhindert werden, indem man den HTTP-Referer- und Origin-Header Ihrer API überprüft. CSRF-Angriffe werden Referer- und Origin-Header haben, die nicht mit Ihrer Anwendung in Verbindung stehen.

Den vollständigen Artikel finden Sie hier: 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 entwirft und implementiert, in Bezug auf die Struktur des Tokens selbst: https://stormpath.com/blog/jwt-the-right-way/

Answer 3

Mit localStorage können Webanwendungen Daten lokal im Browser des Benutzers speichern. Vor HTML5 mussten Anwendungsdaten in Cookies gespeichert werden, die in jedem Serveranforderung enthalten waren. Große Datenmengen können lokal ohne Auswirkungen auf die Leistung der Website gespeichert werden. Obwohl localStorage moderner ist, gibt es einige Vor- und Nachteile für beide Techniken.

Cookies

Vorteile

• Legacy-Unterstützung (es gibt sie schon ewig)
• Persistenten Daten
• Ablaufdaten
• Cookies können als HTTPOnly markiert werden, was XSS-Angriffe auf den Benutzerbrowser während seiner Sitzung möglicherweise einschränkt (garantiert keine vollständige Immunität gegen XSS-Angriffe).

Nachteile

• Jede Domain speichert alle ihre Cookies in einem einzigen String, was das Parsen von Daten erschweren kann
• Daten sind unverschlüsselt, was ein Problem darstellt, da... ... obwohl klein in der Größe, Cookies bei jeder HTTP-Anforderung gesendet werden Begrenzte Größe (4KB)

Lokaler Speicher

Vorteile

• Unterstützung durch die meisten modernen Browser
• Persistenten Daten, die direkt im Browser gespeichert sind
• Gleiche Herkunftsregeln gelten für lokale Speicherdaten
• Wird nicht bei jeder HTTP-Anforderung gesendet
• ~5MB Speicher pro Domain (das sind 5120KB)

Nachteile

• Nicht unterstützt von: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Wenn der Server gespeicherte Clientinformationen benötigt, müssen Sie sie absichtlich senden.

Die Verwendung von localStorage ist fast identisch mit der Sitzung. Sie haben ziemlich genau die gleichen Methoden, sodass der Wechsel von der Sitzung zu localStorage wirklich ein Kinderspiel ist. Wenn jedoch gespeicherte Daten für Ihre Anwendung wirklich wichtig sind, verwenden Sie wahrscheinlich Cookies als Backup, falls localStorage nicht verfügbar ist. Wenn Sie die Browserunterstützung für localStorage überprüfen möchten, führen Sie einfach dieses einfache Skript aus:

/*
* Funktionskörper zur Prüfung, ob der Speicher verfügbar ist
* gibt true zurück, wenn localStorage verfügbar ist und false, wenn nicht
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/*
* Test ausführen und unser benutzerdefiniertes Skript ausführen
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // Sitzungs- und Speichermethoden sind sehr ähnlich
    window.localStorage.setItem(name, 1);
    console.log('localStorage wurde verwendet'); // Protokoll
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie wurde verwendet'); // Protokoll
}

"localStorage-Werte auf sicheren (SSL-)Seiten sind isoliert" wie jemand bemerkt hat, beachten Sie, dass localStorage nicht verfügbar sein wird, wenn Sie von 'http' zu 'https' sicheren Protokoll wechseln, während das Cookie immer noch zugänglich sein wird. Dies ist wichtig zu beachten, wenn Sie mit sicheren Protokollen arbeiten.

Answer 4

Cookies:

1. Eingeführt vor HTML5.
2. Hat ein Ablaufdatum.
3. Wird von JS oder durch Löschen der Browserdaten oder nach Ablaufdatum gelöscht.
4. Wird bei jedem Aufruf an den Server gesendet.
5. Die Kapazität beträgt 4KB.
6. Nur Zeichenfolgen können in Cookies gespeichert werden.
7. Es gibt zwei Arten von Cookies: persistent und Session Cookies.

Local Storage:

1. Eingeführt mit HTML5.
2. Hat kein Ablaufdatum.
3. Wird von JS oder durch Löschen der Browserdaten gelöscht.
4. Sie können auswählen, wann die Daten an den Server gesendet werden sollen.
5. Die Kapazität beträgt 5MB.
6. Daten werden unbegrenzt gespeichert und müssen eine Zeichenfolge sein.
7. Nur eine Art vorhanden.

Answer 5

Schlüsseldifferenzen:

Kapazität:

• Local Storage: 10MB
• Cookies: 4kb

Browserunterstützung:

• Local Storage: HTML5
• Cookies: HTML4, HTML5

Speicherort:

• Local Storage: Nur im Browser
• Cookies: Im Browser & Server

Mit Anfrage senden:

• Local Storage: Ja
• Cookies: Nein

Zugriff von:

• Local Storage: Auf jedem Fenster
• Cookies: Auf jedem Fenster.

Ablaufdatum:

• Local Storage: Nie ablaufen, bis durch JavaScript erledigt.
• Cookies: Ja, haben ein Ablaufdatum.

Hinweis: Verwenden Sie das, was für Sie am besten geeignet ist.