Einführung
Cookie, Sitzung und Token sind Produkte verschiedener Phasen in der Entwicklung von Netzwerkanwendungen. Die drei haben ihre eigenen Vor- und Nachteile und es gibt keine offensichtliche antagonistische Beziehung. Im Gegenteil, sie existieren oft zusammen, was auch der Grund dafür ist für häufige Verwirrung. .
1. Bei der Netzwerkinteraktion aufgetretene Probleme
1.1 Erfahrungen mit Netzwerkinteraktionen
Als Internetnutzer verwenden wir Browser, um fast täglich verschiedene Websites zu besuchen, um unsere täglichen Arbeits- und Lebensanforderungen zu erfüllen. Das aktuelle Netzwerkerlebnis ist für uns immer noch sehr reibungslos, dies ist jedoch beim Besuch der Website in den frühen Tagen nicht der Fall. Im Grunde ist jeder Vorgang, den wir durchführen, ein einmaliger Deal. Warum sagst du das?
1.2 Zustandsloses HTTP-Protokoll
Was ist das zustandslose HTTP-Protokoll?
Das zustandslose HTTP-Protokoll bedeutet, dass das Protokoll keine Speicherkapazität für die Geschäftsverarbeitung hat und sich nicht daran erinnern kann, was es zuvor getan hat. Jede Anfrage ist völlig unabhängig voneinander und verfügt über keine Kontextinformationen.
Das Fehlen eines Status bedeutet, dass, wenn die nachfolgende Verarbeitung frühere Informationen benötigt, kritische Informationen erneut übertragen werden müssen, was zu einem Anstieg der pro Verbindung übertragenen Datenmenge führen kann.
Wenn wir dieses native zustandslose HTTP-Protokoll verwendet haben, müssen wir uns möglicherweise bei jedem Seitenwechsel erneut anmelden, müssen wir also immer noch mit dem Hammer spielen? Benutzer wollen wahrscheinlich ihre Mütter ausschimpfen!
Daher ist es notwendig, die Zustandslosigkeit des HTTP-Protokolls zu lösen und das interaktive Erlebnis der Website zu verbessern, da das Netzwerk von Sternen und Meeren sonst nicht funktionieren kann.
2. Lösungsideen
Im gesamten Prozess der Netzwerkanforderungsinteraktion gibt es auf beiden Seiten nur den Client und den Server, daher ist es notwendig, mit diesen beiden Parteien zu beginnen.
2.1 Der Kunde bezahlt die Rechnung.
Der Kunde kapselt und sendet bei jeder Anfrage seine erforderlichen Informationen an den Server, und der Server kann sie überprüfen und verarbeiten. Wie nachfolgend dargestellt
2.2 Der Server bezahlt
die Rechnung Nachdem der Client die erste Anfrage gestellt hat, beginnt der Server mit der Aufzeichnung, und dann muss der Client in nachfolgenden Anfragen nur die grundlegendsten und minimalsten Informationen senden und benötigt nicht zu viele Informationen. Wie nachfolgend dargestellt
3. Technisches Umsetzungsschema
3.1 Cookie-Schema
Cookie wird immer im Client gespeichert. Je nach Speicherort im Client kann es in Speichercookies und Festplattencookies unterteilt werden.
Das Speichercookie wird vom Browser verwaltet und im Speicher gespeichert. Es verschwindet nach dem Schließen des Browsers und seine Existenzzeit ist kurz. Festplattencookies werden auf der Festplatte gespeichert und haben eine Ablaufzeit. Sofern der Benutzer nicht manuell löscht oder die Ablaufzeit erreicht ist, wird das Festplatten-Cookie nicht gelöscht und seine Existenzdauer ist langfristig.
3.1.1 Definition und Funktion von Cookies
HTTP-Cookies (auch Web-Cookies oder Browser-Cookies genannt) sind kleine Daten, die vom Server an den Browser des Benutzers gesendet und lokal gespeichert werden. Es wird übertragen und an den Server gesendet, wenn der Browser das nächste Mal eine Anfrage an denselben Server stellt.
Gewöhnlich werden Cookies verwendet, um dem Server mitzuteilen, ob zwei Anfragen von demselben Browser kommen, beispielsweise um den Anmeldestatus des Benutzers beizubehalten. Cookies ermöglichen die Aufzeichnung stabiler Zustandsinformationen auf Basis des zustandslosen HTTP-Protokolls.
Cookies werden hauptsächlich auf die folgenden drei Arten verwendet:
Verwaltung des Sitzungsstatus (z. B. Anmeldestatus des Benutzers, Warenkorb und andere Informationen, die aufgezeichnet werden müssen)
Personalisierungseinstellungen (z. B. benutzerdefinierte Einstellungen, Themen usw.)
Verfolgung des Browserverhaltens (z. B. Verfolgung und Analyse des Benutzerverhaltens usw.) )
3.1.2 Serverseitige Erstellung von Cookies
Wenn der Server die HTTP-Anfrage empfängt, kann der Server eine Set-Cookie-Option im Antwortheader hinzufügen.
Normalerweise speichert der Browser das Cookie, nachdem er die Antwort erhalten hat, und sendet dann bei jeder Anforderung an den Server die Cookie-Informationen über den Cookie-Anforderungsheader an den Server. Darüber hinaus können bei Bedarf die Ablaufzeit des Cookies, die Domäne, der Pfad, die Gültigkeitsdauer und die entsprechenden Websites angegeben werden.
3.1.3 Cookie-Interaktion unter B/S-Struktur
Der Server verwendet den Set-Cookie-Antwortheader, um Cookie-Informationen an den Browser des Benutzers zu senden. Geben Sie einige notwendige Informationen in den Text des Cookies ein, z. B. Benutzername, Passwort und andere zugehörige Informationen.
Eine einfache Browser-Cookie-Operation ist wie folgt
Set-Cookie:
RememberMe=deleteMe; Path=/yc-home; Max-Age=0; Expires=Do, 20-Jul-2023 08:04:21 GMT
Jedes Mal, wenn der Client eine neue Anfrage an den Server initiiert, wird der Browser Die zuvor gespeicherten Cookie-Informationen werden über den Cookie-Anfrage-Header an den Server gesendet.
Cookie:
Hm_lvt_085e0fa100dbc0e0e42931c16bf3e9e6=1687672868, 1687845814, 1688968992, 1689921934;
Mal sehen, wie die Informationen im Kopf der Website in unserem Projekt sind
3.1.4 Probleme mit Cookies
Cookies werden häufig verwendet, um Benutzer oder autorisierte Sitzungen zu markieren. Nachdem sie von Browsern ausgegeben wurden, können sie gekapert und für illegale Aktivitäten verwendet werden, was zu Angriffen auf Sitzungen autorisierter Benutzer führen kann, sodass Sicherheitsprobleme bestehen .
Eine andere Situation ist Cross-Site Request Forgery CSRF. Vereinfacht ausgedrückt: Wenn Sie sich beispielsweise auf einer Bank-Website anmelden, melden Sie sich auf einer Phishing-Website an. Wenn Sie bestimmte Vorgänge auf der Phishing-Website ausführen, erhalten Sie möglicherweise Cookie-Informationen im Zusammenhang mit der Website der Bank und senden Sie diese an die Website der Bank. Initiieren Sie Überweisungen und andere illegale Aktivitäten.
Cross-Site-Request-Forgery (englisch: Cross-Site-Request-Forgery), auch bekannt als Ein-Klick-Angriff oder Session-Riding, üblicherweise abgekürzt als CSRF oder XSRF, ist eine Methode, die Benutzer dazu zwingt, unbeabsichtigt auszuführen. Die Angriffsmethode des Vorgangs. Im Gegensatz zum Cross-Site-Scripting (XSS), das das Vertrauen des Benutzers in eine bestimmte Website ausnutzt, nutzt CSRF das Vertrauen der Website in den Webbrowser des Benutzers aus.
Vereinfacht ausgedrückt besteht ein Cross-Site-Request-Angriff darin, dass der Angreifer technische Mittel einsetzt, um den Browser des Benutzers dazu zu verleiten, eine von ihm authentifizierte Website zu besuchen und einige Vorgänge auszuführen (z. B. das Senden von E-Mails, das Senden von Nachrichten und sogar Eigentumsvorgänge wie das Übertragen). Geld und Warenkauf) ).
Da der Browser authentifiziert wurde, wird die besuchte Website als eine echte Benutzeroperation betrachtet und ausgeführt. Dabei wird eine Lücke in der Benutzerauthentifizierung im Web ausgenutzt: Eine einfache Authentifizierung kann nur garantieren, dass die Anfrage vom Browser eines Benutzers stammt, nicht jedoch, dass die Anfrage selbst freiwillig ist.
Es gibt jedoch viele Lösungen für diese Situation, insbesondere bei Finanzseiten wie Banken, bei denen alle sensiblen Vorgänge der Benutzer bestätigt werden müssen und Cookies mit sensiblen Informationen nur einen kurzen Lebenszyklus haben können.
Gleichzeitig sind Cookies in Kapazität und Menge begrenzt und es müssen jedes Mal viele Informationen gesendet werden, was zu einem zusätzlichen Datenverkehr führt und komplexe Verhaltenscookies die Anforderungen nicht erfüllen können.
Bei den oben genannten Problemen handelt es sich nur um Probleme, wenn Cookies zur Realisierung des interaktiven Zustands verwendet werden, nicht aber um das Problem von Cookies selbst.
3.2 Sitzungsschema
3.2.1 Mechanismuskonzept der Sitzung
Wenn das Cookie das Verhalten des Clients ist, dann ist die Sitzung das Verhalten des Servers.
Nachdem der Cookie-Mechanismus zunächst mit dem Server interagiert hat, werden die zur Aufrechterhaltung des Status erforderlichen Informationen in der lokalen Cookie-Datei des Clients gespeichert und dann direkt gelesen und zur Interaktion an den Server gesendet.
Die Sitzung stellt eine Sitzung zwischen dem Server und dem Browser dar und wird vollständig vom Server gesteuert, um Funktionen wie ID-Zuweisung, Speicherung von Sitzungsinformationen und Sitzungsabruf zu implementieren.
Der Sitzungsmechanismus speichert alle Aktivitätsinformationen, Kontextinformationen, Anmeldeinformationen usw. des Benutzers auf dem Server und generiert nur eine eindeutige ID, die an den Client gesendet wird. Nachfolgende Interaktionen haben keine wiederholte Übertragung von Benutzerinformationen und werden durch a ersetzt eindeutige ID. Nennen wir sie vorerst SessionID. Wie nachfolgend dargestellt
3.2.2 Sitzungsinteraktionsprozess
Wenn der Client das Sitzungsobjekt zum ersten Mal anfordert, erstellt der Server eine Sitzung für den Client und berechnet mithilfe eines speziellen Algorithmus eine Sitzungs-ID, um das Sitzungsobjekt zu identifizieren. Wenn der Browser das nächste Mal andere Ressourcen anfordert, wird der Browser
platziert die Sitzungs-ID im Anforderungsheader, und der Server analysiert die Sitzungs-ID nach Erhalt der Anforderung, und der Server findet die Sitzung mit der ID, um die Identität des Anforderers und einige Kontextinformationen zu ermitteln.
3.2.3 Implementierung von Session
Zunächst ist klar, dass zwischen Session und Cookie kein direkter Zusammenhang besteht. Man kann davon ausgehen, dass Cookies nur eine Möglichkeit sind, den Sitzungsmechanismus zu implementieren, und dass andere Methoden ohne Cookies verwendet werden können.
Die Beziehung zwischen Session und Cookie ähnelt der Beziehung zwischen Überstunden und Überstundenvergütung. Es scheint, dass die Beziehung sehr eng ist, aber tatsächlich hat sie nichts damit zu tun.
Es gibt zwei Hauptmethoden zum Implementieren einer Sitzung: Cookie und URL-Umschreiben, wobei Cookie die bevorzugte Methode ist. Da verschiedene moderne Browser die Cookie-Funktion standardmäßig aktivieren, jeder Browser jedoch auch über eine Einstellung verfügt, mit der Cookies ungültig gemacht werden können, ist für den Sitzungsmechanismus ein Backup-Reifen erforderlich.
Die Technik, bei der die Sitzungsidentifikationsnummer als Parameter an die URL-Adresse des Hyperlinks angehängt wird, wird als URL-Rewriting bezeichnet
wie zum Beispiel die Original-URL
http://localhost:9301/zbt/getInsureOrderInfo?outBizNo=1
URL nach dem Umschreiben
http://localhost:9301/zbt/getInsureOrderInfo?sessionid=A8A5647A2E2BOE169B5391D252EDA65C&outBizNo=1
3.2.4 Probleme mit der Sitzung
Da die Sitzungsinformationen auf dem Server gespeichert werden, werden bei einer großen Anzahl von Benutzern die Serverressourcen durch die Sitzungsinformationen belegt wird reduziert Kann nicht ignoriert werden.
Bei großen Websites muss es sich um eine geclusterte und verteilte Serverkonfiguration handeln. Wenn die Sitzungsinformationen aufgrund des Lastausgleichs lokal gespeichert werden, werden die ursprüngliche Anfrage an Maschine A und die Sitzungsinformationen gespeichert. Die nächste Anfrage kommt möglicherweise bei Maschine B an und es sind zu diesem Zeitpunkt keine Sitzungsinformationen auf Maschine B vorhanden.
In diesem Fall führt entweder die wiederholte Erstellung auf Maschine B zu Verschwendung oder die Einführung einer hochverfügbaren Sitzungsclusterlösung, die Einführung eines Sitzungsagenten zur Realisierung des Informationsaustauschs oder die Implementierung eines benutzerdefinierten Hashings für Cluster A, was eigentlich etwas kompliziert ist
3.3 Token-Schema
3.3.1 Kurzbeschreibung des Tokens Token
bezeichnet ein Token, das vom Server generiert und an den Client ausgegeben wird und ein zeiteffizientes Mittel zur Identitätsprüfung darstellt.
Token vermeidet das durch den Sitzungsmechanismus verursachte massive Informationsspeicherproblem und vermeidet auch einige Sicherheitsprobleme des Cookie-Mechanismus. Es wird häufig in modernen mobilen Internetszenarien, domänenübergreifendem Zugriff und anderen Szenarien verwendet.
3.3.2 Einfacher Token-Interaktionsprozess
Der Client übermittelt das Konto und das Kennwort des Benutzers an den Server;
der Server überprüft es und generiert bei Übergabe einen Tokenwert und gibt ihn als Identitätstoken für die nachfolgende Anforderungsinteraktion an den Client zurück;
nachdem der Client den vom Server zurückgegebenen Tokenwert erhalten hat Sie können es lokal speichern und das Token bei jeder zukünftigen Anfrage beim Server mit sich führen und es zur Identitätsprüfung an den Server senden. Nach Erhalt der
Anfrage analysiert der Server die Schlüsselinformationen und generiert sie entsprechend Verschlüsselungsalgorithmus, Schlüssel und Benutzerparameter Das Zeichen wird mit dem Zeichen des Clients verglichen. Wenn sie konsistent sind, wird der Dienst übergeben. Andernfalls wird der Dienst abgelehnt. Nach bestandener Überprüfung kann der Server die entsprechenden Benutzerinformationen entsprechend
abrufen auf die UID im Token und antworten Sie auf die Geschäftsanfrage.
3.3.3 Designidee des Tokens
Am Beispiel des JSON Web Token (JWT) besteht das Token hauptsächlich aus drei Teilen:
Header-Header-Informationen: Zeichnet die Informationen zum verwendeten Verschlüsselungsalgorithmus auf;
Informationen zur Nutzlastlast: Zeichnet Benutzerinformationen und Ablaufzeit usw. auf;
Signatur-Signaturinformationen: Sie werden gemäß dem Verschlüsselungsalgorithmus im Header, den Benutzerinformationen in der Nutzlast usw. generiert Schlüsselschlüssel. Eine wichtige Grundlage für den Server, um den Server zu überprüfen.
Die Informationen des Headers und der Nutzlast werden nicht verschlüsselt, sondern nur die allgemeine Base64-Kodierung. Nach dem Empfang des Tokens entfernt der Server den Header und die Nutzdaten, um Informationen wie Algorithmus, Benutzer und Ablaufzeit zu erhalten. Anschließend generiert er ein Zeichen gemäß seinem eigenen Verschlüsselungsschlüssel und vergleicht es zur Bestimmung mit dem vom Client gesendeten Zeichen die Identität des Kunden, die Legalität.
Auf diese Weise wird die Verschlüsselungs- und Entschlüsselungszeit der CPU gegen Speicherplatz ausgetauscht. Gleichzeitig ist die Bedeutung des Serverschlüssels offensichtlich. Sobald der gesamte Mechanismus durchgesickert ist, wird er zusammenbrechen. Zu diesem Zeitpunkt muss HTTPS berücksichtigt werden .
3.3.4 Funktionen der Token-Lösung
Token können standortübergreifend gemeinsam genutzt werden, um Single Sign-On zu erreichen; der
Token-Mechanismus erfordert nicht viel Speicherplatz. Token enthält Benutzerinformationen und muss nur Statusinformationen auf der Clientseite speichern, was für den Server sehr skalierbar ist. Die
Sicherheit des Token-Mechanismus hängt von der Sicherheit des serverseitigen Verschlüsselungsalgorithmus und -schlüssels ab,
der Token-Mechanismus jedoch nicht ein Allheilmittel.
Zusammenfassend lässt sich sagen, dass
Cookie, Sitzung und Token Produkte verschiedener Phasen in der Entwicklung von Netzwerkanwendungen sind. Die drei haben ihre eigenen Vor- und Nachteile und es gibt keine offensichtliche antagonistische Beziehung. Im Gegenteil, sie existieren oft zusammen ist oft verwirrter Grund.
Cookies konzentrieren sich auf die Speicherung von Informationen, vor allem auf das Kundenverhalten. Sitzung und Token konzentrieren sich auf die Authentifizierung, hauptsächlich auf serverseitiges Verhalten. Die drei Lösungen sind in vielen Szenarien noch lebendig, und nur wenn wir die Szenarien verstehen, können wir die geeignete Lösung auswählen.
Artikel
—————————————————
Copyright-Erklärung: Dieser Artikel ist ein Originalartikel des CSDN-Bloggers „LQzhang_11“ und folgt der CC 4.0 BY-SA-Copyright-Vereinbarung. Zum Nachdruck bitte beifügen der ursprüngliche Quelllink und diese Artikelerklärung.
Ursprünglicher Link: https://blog.csdn.net/LQzhang_11/article/details/131853314