Es gibt zwei Möglichkeiten, Authentifizierungsinformationen im Browser zu speichern:

1. Cookies
2. HTML5-Webspeicher
ol>

In jedem In diesem Fall müssen Sie darauf vertrauen, dass die Browser korrekt implementiert sind und dass Website A nicht auf die Authentifizierungsinformationen für Website B zugreifen kann. In diesem Sinne sind beide Speichermechanismen gleich sicher. Es können jedoch Probleme hinsichtlich der Verwendung auftreten.

Wenn Sie Cookies verwenden:

• Der Browser sendet die Authentifizierungsinformationen bei jeder Anforderung automatisch an die API. Dies kann praktisch sein, solange Sie wissen, dass es passiert.
• Sie müssen sich daran erinnern, dass CSRF eine Sache ist, und sich damit befassen.

Wenn Sie HTML5 Web verwenden Speicher:

• Sie müssen Javascript schreiben, das genau verwaltet, wann und welche Authentifizierungsinformationen gesendet werden.

Der große Unterschied, den die Leute interessieren, ist der bei Cookies. Sie müssen sich um CSRF sorgen. Um CSRF richtig zu handhaben, benötigen Sie normalerweise ein zusätzliches "Synchronizer-Token".

All-in-One-Webframeworks (wie Grails, Rails, wahrscheinlich asp.net) bieten normalerweise ein Einfache Möglichkeit, den CSRF-Schutz zu aktivieren und automatisch Synchronizer-Token in Ihre Benutzeroberfläche einzufügen. Wenn Sie jedoch eine Benutzeroberfläche mit einem clientseitigen Webframework (wie AngularJS oder BackboneJS) schreiben, müssen Sie Javascript schreiben, um das Synchronisierungstoken zu verwalten. In diesem Fall können Sie sich genauso gut für den HTML5-Webspeicher-Ansatz entscheiden und sich nur um ein Token kümmern.

Einige andere Unterschiede werden hier erläutert.

Bearbeiten Eine Google-Suche zeigt dies für asp.net an. Das Synchronisierungstoken wird als "Anforderungsüberprüfungstoken" bezeichnet.

Der beste Weg, um Ihr Zugriffstoken zu schützen, besteht darin, es überhaupt nicht clientseitig zu speichern.

Wie funktioniert das? Generieren Sie zum Zeitpunkt des Generierens des Zugriffstokens ein anderes kryptografisch sicheres PRNG (das Sie dem Zugriffstoken auf dem Server zuordnen), ordnen Sie dies der Sitzungs-ID des Benutzers zu und geben Sie es stattdessen an den Client zurück

Dadurch wird der Angriffsbereich verkleinert, da Sie jetzt ein an eine Sitzung gebundenes Token zurückgeben und beide erforderlich sind, um das Token zu autorisieren. Wenn die Sitzung abläuft, wird das Token natürlich auch neu erstellt, und der Benutzer muss sich erneut authentifizieren, wodurch ein neues Zugriffstoken generiert wird.

Es ist immer noch nicht 100% sicher, Sie müssen jedoch das Token abwägen Möglichkeit, dass so etwas innerhalb einer Benutzersitzung passiert. Auf dieser Grundlage können Sie dann die Ablaufzeiten Ihrer Sitzung / Ihres Tokens an Ihre Bedürfnisse anpassen. Sie müssen jedoch auch auf die Benutzerfreundlichkeit achten. Sie möchten keine Sitzungen nach 5 Minuten ablaufen lassen, da es mühsam sein kann, sich ständig wieder anzumelden ( oder vielleicht können Sie, abhängig von der Art der Anwendung).

ARMOR wurde speziell für diese Anforderung entwickelt. Das Anti-Fälschungs-Token kann an einer beliebigen Stelle auf der Benutzeroberfläche gespeichert werden, die Sie für richtig halten. Die Bibliothek ist mit einer benutzerdefinierten JavaScript-Komponente ausgestattet, die das Token aus der Benutzeroberfläche extrahiert und automatisch in AJAX-Header einfügt.

Hier ist ein Tutorial zu diesem Thema und Hier ist das GitHub-Repo.

Ich würde das Token in einem Cookie mit den folgenden drei Flags speichern: 1. Sicher: Über https2 übertragen. HttpOnly: clientseitiges JS kann es nicht lesen (XSS-Schutz) 3. SameSite (entweder Lax oder Strict): CSRF-Schutz

Auf diese Weise sind Sie immun gegen XSS und CSRF. Sie müssen nur vorsichtig mit SameSite sein, da es relativ neu ist und erst kürzlich von den 4 wichtigsten Browsern (Chrome, FF, Safari, Edge) unterstützt wurde. Siehe: https://caniuse.com/#feat=same -site-cookie-attribute

Weitere Informationen zum Härten von Cookies finden Sie unter https://odino.org/security-hardening-http-cookies/

Alex 'Blog muss informativ sein.

Ein Server stirbt jedes Mal, wenn jemand OAuth auf einer einzelnen Seite als Web-App implementiert. Stoppen Sie den Völkermord! Verwenden Sie einen serverseitigen Proxy! Handeln Sie jetzt!

https://github.com/alexbilbie/alexbilbie.github.com/blob/master/_posts/2014-11-11-oauth-and-javascript .md

Sie müssen das Token in jedem Requset an den Server senden. Es spielt also keine Rolle, ob Sie es in einem Cookie- oder HTML 5-Speicher speichern. Beide sind sichere Speicher, und jeder, der Zugriff auf den Clientcomputer hat, hat ohnehin auch Zugriff auf das Token.

Ich empfehle jedoch, das übermittelte Token im Cookie auf Ihrem Server nicht zu verwenden, um CSRF-Angriffe zu verhindern. Ich denke, es ist eine gute Idee, das Token manuell in jede Anfrage aufzunehmen, die Sie bei Bedarf stellen.

Durch die Verwendung von Cookies wird auch der Anforderungsheader größer, was nicht angemessen ist.