HTTP-Cookies, meist nur „Cookies“ genannt, gibt es schon seit einiger Zeit, sind aber immer noch nicht sehr gut verstanden. Das erste Problem sind viele Missverständnisse, die von Cookies als Spyware oder Viren bis hin zu schlichter Unkenntnis ihrer Funktionsweise reichen. Das zweite Problem ist das Fehlen konsistenter Schnittstellen für die Arbeit mit Cookies. Trotz aller damit verbundenen Probleme sind Cookies ein so wichtiger Bestandteil der Webentwicklung, dass viele unserer bevorzugten Webanwendungen unbrauchbar würden, wenn sie ersatzlos verschwinden würden.
Herkunft von Cookies
Eines der größten Probleme in den Anfängen des Webs war die Verwaltung des Status. Kurz gesagt, der Server hatte keine Möglichkeit zu wissen, ob zwei Anfragen vom selben Browser kamen. Der einfachste Ansatz bestand damals darin, bei der Anforderung ein Token in die Seite einzufügen und dieses Token bei der nächsten Anforderung zurückzugeben. Dies erforderte entweder die Verwendung eines Formulars mit einem versteckten Feld, das das Token enthält, oder die Übergabe des Tokens als Teil der Abfragezeichenfolge der URL. Bei beiden Lösungen handelte es sich um stark manuelle Vorgänge, die fehleranfällig waren.
Lou Montulli, einem damaligen Mitarbeiter von Netscape Communications, wird die Anwendung des Konzepts zugeschrieben: „magische Kekse1994 begann er mit der Webkommunikation. Das Problem, das er zu lösen versuchte, war das des ersten Warenkorbs im Internet, der heute eine tragende Säule auf allen Einkaufsseiten ist. SeinOriginalspezifikationbietet grundlegende Informationen zur Funktionsweise von Cookies, die in formalisiert wurdenRFC 2109(die Referenz für die meisten Browser-Implementierungen) und entwickelte sich schließlich zuRFC 2965. Montulli würde auch die Vereinigten Staaten erhaltenPatentfür Kekse. Netscape Navigator unterstützte Cookies seit seiner ersten Version und Cookies werden jetzt von allen Webbrowsern unterstützt.
Was ist ein Cookie?
Ein Cookie ist ganz einfach eine kleine Textdatei, die von einem Browser auf dem Rechner des Nutzers gespeichert wird. Cookies sind reiner Text; Sie enthalten keinen ausführbaren Code. Eine Webseite oder ein Server weist einen Browser an, diese Informationen zu speichern und sie dann basierend auf einer Reihe von Regeln bei jeder weiteren Anfrage zurückzusenden. Webserver können diese Informationen dann verwenden, um einzelne Benutzer zu identifizieren. Die meisten Websites, die eine Anmeldung erfordern, setzen in der Regel ein Cookie, sobald Ihre Anmeldeinformationen überprüft wurden, und Sie können dann zu allen Teilen der Website navigieren, solange dieses Cookie vorhanden und validiert ist. Auch hier enthält das Cookie lediglich Daten und ist an sich nicht schädlich.
Cooke-Kreation
Ein Webserver gibt ein zu speicherndes Cookie an, indem er einen HTTP-Header mit dem Namen sendetSet-Cookie. Das Format derSet-Cookieheader ist eine Zeichenfolge wie folgt (Teile in eckigen Klammern sind optional):
Set-Cookie: Wert[; läuft ab=Datum][; domain=domain][; path=Pfad][; sicher]Der erste Teil des Headers, der Wert, ist normalerweise eine Zeichenfolge im FormatName=Wert. Tatsächlich gibt die ursprüngliche Spezifikation an, dass dies das zu verwendende Format ist, Browser führen jedoch keine solche Validierung der Cookie-Werte durch. Sie können tatsächlich eine Zeichenfolge ohne Gleichheitszeichen angeben und sie wird trotzdem gespeichert. Dennoch besteht die häufigste Verwendung darin, einen Cookie-Wert als anzugebenName=Wert(und die meisten Schnittstellen unterstützen dies ausschließlich).
Wenn ein Cookie vorhanden ist und die optionalen Regeln dies zulassen, wird der Cookie-Wert bei jeder nachfolgenden Anfrage an den Server gesendet. Der Cookie-Wert wird in einem HTTP-Header namens gespeichertPlätzchenund enthält nur den Cookie-Wert ohne andere Optionen. Wie zum Beispiel:
Cookie: WertDie mit angegebenen OptionenSet-Cookiedienen nur der Verwendung durch den Browser und können nicht mehr abgerufen werden, sobald sie festgelegt wurden. Der Cookie-Wert ist genau dieselbe Zeichenfolge, die mit angegeben wurdeSet-Cookie; Es erfolgt keine weitere Interpretation oder Kodierung des Wertes. Wenn für die angegebene Anfrage mehrere Cookies vorhanden sind, werden diese durch ein Semikolon und ein Leerzeichen getrennt, z. B.:
Cookie: Wert1; Wert2; Name1=Wert1Serverseitige Frameworks bieten in der Regel Funktionen zum Parsen von Cookies und zum programmgesteuerten Bereitstellen ihrer Werte.
Cookie-Kodierung
Es gibt einige Verwirrung hinsichtlich der Codierung eines Cookie-Werts. Die weit verbreitete Meinung ist, dass Cookie-Werte URL-codiert sein müssen. Dies ist jedoch ein Trugschluss, obwohl es sich um die De-facto-Implementierung handelt. Die ursprüngliche Spezifikation besagt, dass nur drei Arten von Zeichen codiert werden müssen: Semikolon, Komma und Leerzeichen. Die Spezifikation weist darauf hin, dass die URL-Kodierung verwendet werden darf, erfordert diese jedoch nicht. Der RFC erwähnt die Codierung überhaupt nicht. Dennoch führen fast alle Implementierungen eine Art URL-Codierung für Cookie-Werte durch. Im Fall vonName=WertIn einigen Formaten werden Name und Wert normalerweise separat codiert, während das Gleichheitszeichen unverändert bleibt.
Die Ablaufoption
Jede der Optionen nach dem Cookie-Wert wird durch ein Semikolon und ein Leerzeichen getrennt und jede legt Regeln fest, wann das Cookie an den Server zurückgesendet werden soll. Die erste Option istläuft ab, die angibt, wann das Cookie nicht mehr an den Server gesendet werden soll und daher vom Browser gelöscht werden kann. Der Wert für diese Option ist ein Datum im FormatWdy, TT-Mo-JJJJ HH:MM:SS GMTwie zum Beispiel:
Set-Cookie: name=Nicholas; läuft ab=Sa, 02. Mai 2009 23:38:25 GMTOhne dasläuft abOption: Ein Cookie hat eine Lebensdauer von einer einzelnen Sitzung. Eine Sitzung gilt als beendet, wenn der Browser geschlossen wird. Daher sind Sitzungscookies nur vorhanden, solange der Browser geöffnet bleibt. Aus diesem Grund wird beim Anmelden bei einer Webanwendung häufig ein Kontrollkästchen angezeigt, in dem Sie gefragt werden, ob Ihre Anmeldeinformationen gespeichert werden sollen: Wenn Sie „Ja“ auswählen, dann einläuft abOption ist an das Login-Cookie angehängt. Wenn dieläuft abWird die Option auf ein Datum gesetzt, das in der Vergangenheit liegt, wird das Cookie sofort gelöscht.
Die Domain-Option
Die nächste Option istDomain, der die Domain(s) angibt, für die das Cookie gesendet werden soll. Standardmäßig,Domainist auf den Hostnamen der Seite eingestellt, die das Cookie setzt, sodass der Cookie-Wert jedes Mal gesendet wird, wenn eine Anfrage an denselben Hostnamen gestellt wird. Die Standarddomäne für ein auf dieser Website gesetztes Cookie wäre beispielsweisewww.nczonline.net. DerDomainDie Option wird verwendet, um die Anzahl der Domänen zu erweitern, für die der Cookie-Wert gesendet wird. Probe:
Set-Cookie: name=Nicholas; domain=nczonline.netBetrachten Sie den Fall eines großen Netzwerks wie zYahoo!das hat viele Seiten in Form vonName.yahoo.com (z. B.my.yahoo.com,Finance.yahoo.com, usw.). Für alle diese Websites kann ein einziger Cookie-Wert festgelegt werden, indem die festgelegt wirdDomainOption zu einfachyahoo.com. Der Browser führt einen Endvergleich dieses Werts und des Hostnamens durch, an den eine Anfrage gesendet wird (d. h. er beginnt den Vergleich am Ende der Zeichenfolge) und sendet den entsprechenden WertPlätzchenHeader, wenn es eine Übereinstimmung gibt.
Der für die festgelegte WertDomainDie Option muss Teil des Hostnamens sein, der die sendetSet-CookieHeader. Ich konnte zum Beispiel kein Cookie setzengoogle.comdenn das würde ein Sicherheitsproblem mit sich bringen. UngültigDomainOptionen werden einfach ignoriert.
Die Pfadoption
Eine andere Möglichkeit, zu kontrollieren, wann diePlätzchenDer gesendete Header dient zur Angabe desWegMöglichkeit. Ähnlich wie bei der Domain-Option,WegGibt einen URL-Pfad an, der vor dem Senden in der angeforderten Ressource vorhanden sein mussPlätzchenHeader. Dieser Vergleich erfolgt durch den zeichenweisen Vergleich des Optionswerts mit dem Anfang der Anforderungs-URL. Wenn die Zeichen übereinstimmen, dannPlätzchenHeader wird gesendet. Probe:
Set-Cookie: name=Nicholas; path=/blogIn diesem Beispiel ist dieWegOption würde passen/blog,/blogroll, usw.; alles, was damit beginnt/blogist gültig. Beachten Sie, dass dieser Vergleich nur einmal durchgeführt wirdDomainOption wurde überprüft. Der Standardwert fürWegOption ist der Pfad der URL, die die gesendet hatSet-CookieHeader.
Die sichere Option
Die letzte Option istsicher. Im Gegensatz zu den anderen Optionen ist dies nur ein Flag und es ist kein zusätzlicher Wert angegeben. Ein sicheres Cookie wird nur dann an den Server gesendet, wenn eine Anfrage über SSL und das HTTPS-Protokoll erfolgt. Der Gedanke, dass der Inhalt des Cookies von hohem Wert ist und bei der Übermittlung als Klartext potenziell schädlich sein könnte. Probe:
Set-Cookie: name=Nicholas; sicherTatsächlich sollten vertrauliche oder sensible Informationen niemals in Cookies gespeichert oder übertragen werden, da der gesamte Mechanismus von Natur aus unsicher ist. Standardmäßig werden Cookies, die über eine HTTPS-Verbindung gesetzt werden, automatisch als sicher eingestuft.
Cookie-Pflege und -Lebenszyklus
Für ein einzelnes Cookie können beliebig viele Optionen angegeben werden, und diese Optionen können in beliebiger Reihenfolge angezeigt werden. Zum Beispiel:
Set-Cookie: name=Nicholas; domain=nczonline.net; path=/blogDieses Cookie weist vier Erkennungsmerkmale auf: das CookieName, DieDomain, DieWeg, und dassicherFlagge. Um den Wert dieses Cookies in Zukunft zu ändern, ein andererSet-CookieDer Header muss mit demselben Cookie-Namen, derselben Domäne und demselben Pfad gesendet werden. Zum Beispiel:
Set-Cookie: name=Greg; domain=nczonline.net; path=/blogDadurch wird der Wert des ursprünglichen Cookies durch einen neuen überschrieben. Wenn Sie jedoch auch nur eine dieser Optionen ändern, entsteht ein völlig anderes Cookie, wie zum Beispiel:
Set-Cookie: name=Nicholas; domain=nczonline.net; path=/Nach der Rückgabe dieses Headers gibt es nun zwei Cookies mit dem Namen „name“. Wenn Sie eine Seite unter aufrufen würdenwww.nczonline.net/blog, würde der folgende Header in der Anfrage enthalten sein:
Cookie: Name=Greg; Name=NikolausIn diesem Header gibt es zwei Cookies mit dem Namen „Name“, wobei das spezifischere istWegwird zuerst zurückgegeben. Die Cookie-Zeichenfolge wird immer in der Reihenfolge zurückgegeben, in der sie am spezifischsten istDomänenpfad-sicherTupel bis am wenigsten spezifisch. Angenommen, ich bin dabeiwww.nczonline.net/blogund ein weiteres Cookie mit Standardeinstellungen setzen:
Set-Cookie: name=MikeDer zurückgegebene Header lautet nun:
Cookie: Name=Mike; name=Greg; Name=NikolausDa das Cookie mit dem Wert „Mike“ den Hostnamen (www.nczonline.net) für seine Domäne und den vollständigen Pfad (/blog) als Pfad ist es spezifischer als die beiden anderen.
Verwendung von Ablaufdaten
Wenn ein Cookie mit einem Ablaufdatum erstellt wird, bezieht sich dieses Ablaufdatum auf das namentlich identifizierte Cookie.Domain-Weg-sicher. Um das Ablaufdatum eines Cookies zu ändern, müssen Sie genau dasselbe Tupel angeben. Wenn Sie den Wert eines Cookies ändern, müssen Sie nicht jedes Mal das Ablaufdatum festlegen, da es nicht Teil der identifizierenden Informationen ist. Beispiel:
Set-Cookie: name=Mike; läuft ab=Sa, 03. Mai 2025 17:44:22 GMTDas Ablaufdatum des Cookies wurde nun festgelegt. Wenn ich also das nächste Mal den Wert des Cookies ändern möchte, kann ich einfach seinen Namen verwenden:
Set-Cookie: name=MattDas Ablaufdatum dieses Cookies hat sich nicht geändert, da die identifizierenden Merkmale des Cookies dieselben sind. Tatsächlich ändert sich das Ablaufdatum erst, wenn Sie es erneut manuell ändern. Das bedeutet, dass ein Sitzungscookie innerhalb derselben Sitzung zu einem dauerhaften Cookie (also einem Cookie, das mehrere Sitzungen überdauert) werden kann, das Gegenteil ist jedoch nicht der Fall. Um ein dauerhaftes Cookie in ein Sitzungscookie umzuwandeln, müssen Sie das dauerhafte Cookie löschen, indem Sie dessen Ablaufdatum auf einen Zeitpunkt in der Vergangenheit festlegen und dann ein Sitzungscookie mit demselben Namen erstellen.
Beachten Sie, dass das Ablaufdatum mit der Systemzeit auf dem Computer verglichen wird, auf dem der Browser ausgeführt wird. Es gibt keine Möglichkeit zu überprüfen, ob die Systemzeit mit der Serverzeit synchronisiert ist. Daher können Fehler auftreten, wenn eine Diskrepanz zwischen der Systemzeit und der Serverzeit besteht.
Automatische Cookie-Entfernung
Es gibt einige Gründe, warum ein Cookie möglicherweise automatisch vom Browser entfernt wird:
- Sitzungscookies werden entfernt, wenn die Sitzung beendet ist (Browser geschlossen).
- Dauerhafte Cookies werden entfernt, wenn das Ablaufdatum und die Ablaufzeit erreicht sind.
- Wenn das Cookie-Limit des Browsers erreicht ist, werden Cookies entfernt, um Platz für das zuletzt erstellte Cookie zu schaffen. Weitere Einzelheiten finden Sie in meinem Beitrag unterCookie-Einschränkungen.
Die Cookie-Verwaltung ist wichtig, um solche Fälle der automatischen Entfernung zu vermeiden, wenn sie unbeabsichtigt sind.
Cookie-Einschränkungen
Es gibt eine Reihe von Einschränkungen für Cookies, um Missbrauch zu verhindern und sowohl den Browser als auch den Server vor schädlichen Auswirkungen zu schützen. Es gibt zwei Arten von Einschränkungen: Anzahl der Cookies und Gesamtgröße der Cookies. Die ursprüngliche Spezifikation sah ein Limit von 20 Cookies pro Domäne vor, das von frühen Browsern übernommen und bis zum Internet Explorer 7 fortgesetzt wurde. Während eines der Updates von Microsoft wurden sieDas Cookie-Limit wurde erhöhtim IE 7 bis 50 Cookies. Auch IE 8 hat maximal 50 Cookies pro Domain. Firefox hat ebenfalls ein Limit von 50 Cookies, während Opera ein Limit von 30 Cookies hat. In Safari und Chrome gibt es keine Begrenzung für die Anzahl der Cookies pro Domain.
Die maximale Größe aller an den Server gesendeten Cookies ist seit der ursprünglichen Cookie-Spezifikation gleich geblieben: 4 KB. Alles, was über diesem Limit liegt, wird gekürzt und nicht an den Server gesendet.
Untercookies
Aufgrund der Beschränkung der Cookie-Anzahl sind Entwickler auf die Idee gekommen, Subcookies zu verwenden, um den ihnen zur Verfügung stehenden Speicherplatz zu erhöhen. Untercookies sind Name-Wert-Paare, die in einem Cookie-Wert gespeichert werden und normalerweise ein Format ähnlich dem folgenden haben:
name=a=b&c=d&e=f&g=hDieser Ansatz ermöglicht es einem einzelnen Cookie, mehrere Name-Wert-Kombinationen zu speichern, ohne dass das Cookie-Limit des Browsers überschritten wird. Der Nachteil beim Erstellen von Cookies in diesem Format besteht darin, dass zum Extrahieren der Werte eine benutzerdefinierte Analyse erforderlich ist, anstatt sich auf das viel einfachere Cookie-Format zu verlassen. Einige serverseitige Frameworks beginnen, die Speicherung von Subcookies zu unterstützen. DerYUI-Cookie-Dienstprogramm, das ich geschrieben habe, unterstützt das Lesen/Schreiben von Subcookies aus JavaScript.
Cookies in JavaScript
Sie können Cookies in JavaScript erstellen, bearbeiten und entfernen, indem Sie die verwendendocument.cookieEigentum. Diese Eigenschaft fungiert alsSet-CookieHeader bei Zuweisung an und alsPlätzchenHeader beim Lesen. Wenn Sie ein Cookie erstellen, müssen Sie eine Zeichenfolge verwenden, die dasselbe Format hat wieSet-Cookieerwartet:
document.cookie="name=Nicholas; domain=nczonline.net; path=/";Festlegen des Werts vondocument.cookie nichtLöschen Sie alle auf der Seite gespeicherten Cookies. Es erstellt oder ändert einfach das in der Zeichenfolge angegebene Cookie. Wenn das nächste Mal eine Anfrage an den Server gestellt wird, werden diese Cookies zusammen mit allen anderen, die über erstellt wurden, gesendetSet-Cookie. Es ist kein Unterschied zwischen diesen Cookies erkennbar.
Um Cookie-Werte in JavaScript abzurufen, lesen Sie einfach ausdocument.cookieEigentum. Die zurückgegebene Zeichenfolge hat dasselbe Format wie diePlätzchenHeader-Wert, daher werden mehrere Cookies durch ein Semikolon und ein Leerzeichen getrennt. Beispiel:
name1=Greg; name2=NikolausAus diesem Grund müssen Sie die Cookie-Zeichenfolge manuell analysieren, um die tatsächlichen Cookie-Daten zu extrahieren. Es gibt zahlreiche Ressourcen, die Cookie-Parsing-Ansätze für JavaScript beschreiben, darunter mein Buch,Professionelles JavaScript, deshalb werde ich hier nicht näher darauf eingehen. Oft ist es einfacher, eine bereits vorhandene JavaScript-Bibliothek wie die zu verwendenYUI-Cookie-Dienstprogrammum mit Cookies in JavaScript umzugehen, anstatt diese Algorithmen manuell neu zu erstellen.
Die durch den Zugriff auf document.cookie zurückgegebenen Cookies folgen denselben Zugriffsregeln wie an den Server gesendete Cookies. Um über JavaScript auf Cookies zugreifen zu können, muss sich die Seite in derselben Domain befinden, denselben Pfad haben und über dieselbe Sicherheitsstufe verfügen, die durch das Cookie angegeben wird.
Hinweis: Es ist nicht möglich, die Optionen für Cookies abzurufen, nachdem sie über JavaScript festgelegt wurden, sodass Sie keine Ahnung haben, was das bedeutetDomain,Weg, Ablaufdatum, odersicherFlagge.
Nur HTTP-Cookies
Microsoft hat im Internet Explorer 6 SP1 eine neue Option für Cookies eingeführt: Nur-HTTP-Cookies. Die Idee hinter Nur-HTTP-Cookies besteht darin, einen Browser anzuweisen, dass ein Cookie niemals über JavaScript über das zugänglich sein solltedocument.cookieEigentum. Diese Funktion wurde als Sicherheitsmaßnahme entwickelt, um Cross-Site-Scripting-Angriffe (XSS) zu verhindern, die durch den Diebstahl von Cookies über JavaScript erfolgen (ich werde Sicherheitsprobleme mit Cookies in einem anderen Beitrag besprechen, dieser ist ohnehin lang genug). Heute unterstützen Firefox 2.0.0.5+, Opera 9.5+ und Chrome auch reine HTTP-Cookies. Safari ab 3.2 funktioniert immer noch nicht.
Um ein reines HTTP-Cookie zu erstellen, fügen Sie einfach ein hinzuHttpOnlyFlag zu Ihrem Cookie:
Set-Cookie: name=Nicholas; HttpOnlySobald dieses Flag gesetzt ist, erfolgt kein Zugriff überdocument.cookiezu diesem Cookie. Internet Explorer geht noch einen Schritt weiter und erlaubt keinen Zugriff auf diesen Header über diegetAllResponseHeaders()odergetResponseHeader()Methoden aufXMLHttpRequestwährend andere Browser dies noch zulassen. FeuerfuchsDiese Schwachstelle wurde behobenin 3.0.6 gibt es sie allerdings nochverschiedene Browser-Schwachstellenherumschweben (vollständige Liste der unterstützten Browser).
Sie können von JavaScript aus keine reinen HTTP-Cookies setzen, was sinnvoll ist, da Sie sie auch nicht von JavaScript lesen können.
Abschluss
Um Cookies effektiv nutzen zu können, muss man viel über Cookies wissen und verstehen. Es ist wirklich erstaunlich, wie eine Technik, die vor mehr als zehn Jahren entwickelt wurde, immer noch fast genauso verwendet wird, wie sie erstmals implementiert wurde. Dieser Beitrag ist eine Anleitung zu den Grundlagen, die jeder über Cookies in Browsern wissen sollte, stellt aber keineswegs eine vollständige Referenz dar. Cookies sind heutzutage ein wichtiger Bestandteil des Webs und ihre unsachgemäße Verwaltung kann zu allen möglichen Problemen führen, von einer schlechten Benutzererfahrung bis hin zu Sicherheitslücken. Ich hoffe, dass dieser Artikel etwas Licht auf die Magie von Keksen geworfen hat.
