it-swarm.com.de

Lokaler Speicher vs Cookies

Ich möchte die Ladezeiten auf meinen 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) bei der Verwendung des lokalen Speichers, um die Cookie-Funktionalität zu ersetzen, mit Ausnahme der offensichtlichen Kompatibilitätsprobleme?

948
Gio Borje

Cookies und lokale Speicherung dienen unterschiedlichen Zwecken. Cookies dienen in erster Linie zum Lesen von serverseitig, der lokale Speicher kann nur von clientseitig 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, wechseln Sie auf jeden Fall. 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 so). Dies ist möglicherweise in Ordnung, wenn der Server für jede Anforderung nur eine kleine Teilmenge der Gesamtdaten benötigt.

Sie möchten Ihren Sitzungscookie so oder so als Cookie belassen.

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

  1. Abgesehen davon, dass Cookies ein altes Verfahren zum Speichern von Daten sind, gibt es für Sie ein Limit von 4096 Bytes (tatsächlich 4095) - je Cookie. Lokaler Speicher ist so groß wie 5 MB pro Domain - SO Question erwähnt es auch

  2. localStorage ist eine Implementierung der Storage Schnittstelle. Es speichert Daten mit kein Ablaufdatum und wird nur durch JavaScript oder Löschen des Browser-Cache/lokal gespeicherter Daten gelöscht - im Gegensatz zum Ablauf von Cookies.

1181
jpsimons

Im Zusammenhang mit JWTs hat Stormpath einen ziemlich hilfreichen Artikel verfasst, in dem die möglichen Arten der Speicherung und die (Un-) Vorteile der einzelnen Methoden beschrieben werden.

Außerdem erhalten Sie einen kurzen Überblick über XSS- und CSRF-Angriffe und wie Sie diese bekämpfen können.

Ich habe einige kurze Ausschnitte aus dem Artikel unten angehängt, falls der Artikel offline geschaltet wird oder die Website ausfällt.

Lokaler Speicher

Probleme:

Auf Web Storage (localStorage/sessionStorage) kann über JavaScript in derselben Domain zugegriffen werden. Dies bedeutet, dass jedes JavaScript, das auf Ihrer Website ausgeführt wird, Zugriff auf den Webspeicher hat und daher anfällig für XSS-Angriffe (Cross-Site Scripting) sein kann. Kurz gesagt, XSS ist eine Art von Sicherheitsanfälligkeit, bei der ein Angreifer JavaScript einschleusen kann, das auf Ihrer Seite ausgeführt wird. Bei einfachen XSS-Angriffen wird versucht, JavaScript über Formulareingaben zu injizieren, wobei der Angreifer eine Warnung ausgibt ("Sie sind gehackt"). in ein Formular, um zu sehen, ob es vom Browser ausgeführt wird und von anderen Benutzern angezeigt werden kann.

Prävention:

Um XSS zu verhindern, besteht die allgemeine Antwort darin, alle nicht vertrauenswürdigen Daten zu entziehen und zu codieren. Aber das ist noch lange nicht alles. Im Jahr 2015 verwenden moderne Web-Apps JavaScript, das auf CDNs oder auf externen Infrastrukturen 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 von Ihnen verwendeten Skripte beschädigt ist? Bösartiges JavaScript kann in die Seite eingebettet werden, und der Webspeicher ist gefährdet. Durch diese Art von XSS-Angriffen kann jeder, der Ihre Website besucht, ohne dessen Wissen auf den Web-Speicher zugreifen. Dies ist wahrscheinlich der Grund, warum eine Reihe von Organisationen raten, nichts Wertvolles zu speichern oder Informationen im Web-Speicher zu vertrauen. Dies umfasst Sitzungskennungen und Token.

Als Speichermechanismus erzwingt Web Storage während der Übertragung keine sicheren Standards. Wer Web Storage liest und nutzt, muss mit gebührender Sorgfalt sicherstellen, dass das JWT immer über HTTPS und niemals über HTTP gesendet wird.

Kekse

Probleme:

Cookies, die mit der HttpOnly-Cookie-Flagge verwendet werden, sind über JavaScript nicht verfügbar und gegen XSS immun. Sie können auch das Secure-Cookie-Flag setzen, um sicherzustellen, dass das Cookie nur über HTTPS gesendet wird. Dies ist einer der Hauptgründe, warum Cookies in der Vergangenheit zum Speichern von Token oder Sitzungsdaten eingesetzt wurden. Moderne Entwickler zögern, Cookies zu verwenden, da sie traditionell den Status auf dem Server benötigen und damit gegen RESTful Best Practices verstoßen. Cookies als Speichermechanismus erfordern nicht, dass der Status auf dem Server gespeichert wird, wenn Sie eine 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 für eine andere Art von Angriff anfällig: Cross-Site Request Forgery (CSRF). Ein CSRF-Angriff ist ein Angriffstyp, der auftritt, wenn eine böswillige Website, E-Mail oder ein Blog den Webbrowser eines Benutzers dazu veranlasst, eine unerwünschte Aktion auf einer vertrauenswürdigen Website auszuführen, auf der der Benutzer derzeit authentifiziert ist. Dies ist ein Exploit, wie der Browser mit Cookies umgeht. Ein Cookie kann nur an die Domänen gesendet werden, in denen es zulässig ist. Standardmäßig ist dies die Domäne, in der das Cookie ursprünglich festgelegt wurde. Der Cookie wird unabhängig davon, ob Sie sich auf galaxies.com oder hahagonnahackyou.com befinden, für eine Anfrage gesendet.

Prävention:

CSRF kann mithilfe synchronisierter Token-Muster verhindert werden. Das hört sich kompliziert an, aber alle modernen Web-Frameworks unterstützen dies.

AngularJS bietet beispielsweise eine Lösung, mit der überprüft werden kann, ob nur Ihre Domain auf das Cookie zugreifen kann. Direkt aus AngularJS-Dokumenten:

Bei der Ausführung von XHR-Anforderungen liest der $ http-Dienst ein Token aus einem Cookie (standardmäßig XSRF-TOKEN) und legt es als HTTP-Header (X-XSRF-TOKEN) fest. Da nur JavaScript, das auf Ihrer Domain ausgeführt wird, das Cookie lesen kann, kann Ihr Server sicher sein, dass die XHR von JavaScript stammt, das auf Ihrer Domain ausgeführt wird. Sie können diesen CSRF-Schutz zustandslos machen, indem Sie eine xsrfToken JWT-Behauptung einfügen:

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

Durch die Nutzung des CSRF-Schutzes Ihres Web-App-Frameworks sind Cookies für die Speicherung einer JWT absolut zuverlässig. CSRF kann auch teilweise verhindert werden, indem der HTTP-Referer und der Origin-Header in Ihrer API überprüft werden. CSRF-Angriffe enthalten Referer- und Origin-Header, die nicht mit Ihrer Anwendung zusammenhängen.

Den vollständigen Artikel finden Sie hier: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Sie finden auch einen hilfreichen Artikel darüber, wie JWTs in Bezug auf die Struktur des Tokens selbst am besten entworfen und implementiert werden können: https://stormpath.com/blog/jwt-the-right-way/

193
XtraSimplicity

Mit localStorage können Webanwendungen Daten lokal im Browser des Benutzers speichern. Vor HTML5 mussten Anwendungsdaten in Cookies gespeichert werden, die in jeder Serveranfrage enthalten waren. Große Datenmengen können lokal gespeichert werden, ohne die Leistung der Website zu beeinträchtigen. Obwohl localStorage moderner ist, gibt es bei beiden Techniken einige Vor- und Nachteile.

Kekse

Vorteile

  • Legacy-Unterstützung (es gibt sie schon immer)
  • Persistente Daten
  • Ablaufdaten

Nachteile

  • Jede Domain speichert alle Cookies in einer einzigen Zeichenfolge, was das Parsen von Daten erschweren kann
  • Daten sind unverschlüsselt, was zu einem Problem wird, da ... ... Cookies trotz ihrer geringen Größe bei jeder HTTP-Anfrage gesendet werden. Begrenzte Größe (4 KB)
  • Die SQL-Injektion kann über ein Cookie erfolgen

Lokaler Speicher

Vorteile

  • Unterstützung durch die meisten modernen Browser
  • Persistente Daten, die direkt im Browser gespeichert werden
  • Same-Origin-Regeln gelten für lokale Speicherdaten
  • Wird nicht bei jeder HTTP-Anfrage gesendet
  • ~ 5 MB Speicherplatz pro Domain (das sind 5120 KB)

Nachteile

  • Nicht von irgendetwas zuvor 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, müssen Sie diese absichtlich senden.

localStorage Die Verwendung ist fast identisch mit der in der ersten Sitzung. Sie haben ziemlich genaue Methoden, so dass der Wechsel von der Sitzung zu localStorage wirklich ein Kinderspiel ist. Wenn jedoch gespeicherte Daten für Ihre Anwendung wirklich entscheidend sind, werden Sie wahrscheinlich Cookies als Backup verwenden, falls localStorage nicht verfügbar ist. Wenn Sie die Browser-Unterstützung für localStorage überprüfen möchten, müssen Sie nur dieses einfache Skript ausfü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" Beachten Sie, dass localStorage nicht verfügbar ist, wenn Sie von "http" zu "https" wechseln, wobei das Cookie weiterhin verwendet wird erreichbar sein. Dies ist wichtig, wenn Sie mit sicheren Protokollen arbeiten.

86
DevWL

Erwähnenswert ist auch, dass localStorage in einigen Versionen von Mobile Safari nicht verwendet werden kann, wenn Benutzer im "privaten" Modus surfen.

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

Hinweis: Ab iOS 5.1 speichert Safari Mobile localStorage-Daten im Cache-Ordner, der auf Anweisung des Betriebssystems gelegentlich bereinigt wird, in der Regel, wenn der Speicherplatz knapp ist. Der private Browsing-Modus von Safari Mobile verhindert außerdem das vollständige Schreiben in localStorage.

8
benjaminz

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

LOCAl- und Sitzungsspeicherdaten im JSON-Format, daher einfach zu analysieren. Cookies-Daten haben jedoch ein Zeichenfolgenformat.

7

Die Geschwindigkeit des lokalen Speichers hängt stark vom verwendeten Browser und vom Betriebssystem ab. Chrome oder Safari auf einem Mac sind möglicherweise viel schneller als Firefox auf einem PC, insbesondere mit neueren APIs. Testen ist wie immer Ihr Freund (ich konnte keine Benchmarks finden).

Ich sehe wirklich keinen großen Unterschied zwischen Cookies und lokalem Speicher. Darüber hinaus sollten Sie sich mehr Gedanken über Kompatibilitätsprobleme machen: Nicht alle Browser unterstützen die neuen HTML5-APIs, daher sind Cookies die beste Wahl für Geschwindigkeit und Kompatibilität.

7
pop850