HTTP-Cookie


aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Ein Cookie ([ˈkʊki]; englisch „Keks“) ist eine Textinformation, die die besuchte Website (hier „Server“) über den Browser im Rechner des Betrachters („Client“) platziert. Der Cookie wird entweder vom Webserver an den Browser gesendet oder von einem Skript (etwa JavaScript) in der Website erzeugt. Der Client sendet die Cookie-Information bei späteren, neuen Besuchen dieser Seite mit jeder Anforderung wieder an den Server.

Anwendungen

HTTP ist ein zustandsloses Protokoll, daher sind für den Webserver die Seitenaufrufe voneinander unabhängig. Eine Webanwendung, deren Interaktion mit dem Benutzer über mehrere Seitenaufrufe andauert, muss mit Tricks arbeiten, um den Teilnehmer über mehrere Zugriffe hinweg identifizieren zu können. Dazu kann in einem Cookie vom Server eine eindeutige Session-ID gespeichert werden, um genau diesen Client bei weiteren Aufrufen wiederzuerkennen. Aus Sicherheitsgründen wird beim Electronic Banking eher ein Einmal-Token pro Seitenaufruf eingesetzt.

Online-Shops können Cookies verwenden, um Waren in virtuellen Einkaufskörben zu sammeln. Der Kunde kann damit Artikel in den Einkaufskorb legen und sich weiter auf der Website umschauen, um danach die Artikel zusammen zu kaufen. Die Identifikation des Warenkorbs bzw. der Session des Benutzers wird im Cookie abgelegt, die Artikel-Kennungen werden auf dem Webserver diesem Warenkorb bzw. der Session des Benutzers zugeordnet. Erst bei der Bestellung werden diese Informationen serverseitig ausgewertet.

Damit bei Webanwendungen Benutzeraktionen und -eingaben, die für den Server bestimmt sind, bei Abbrüchen der Verbindung zum Server (zum Beispiel in Mobilfunknetzen) nicht verlorengehen, können Cookies zur Zwischenspeicherung eingesetzt werden. Bei Wiederherstellung der Verbindung werden sie vom Server abgefragt. Die Webanwendung erkennt dabei die Reihenfolge, in der die Cookies erzeugt wurden, und markiert bereits verarbeitete Cookies oder löscht deren Inhalt. Weil bei dieser Verwendung unter Umständen viele Cookies erzeugt werden, die frühestens beim Schließen des Browsers gelöscht werden, der Speicherplatz des Browsers für Cookies aber beschränkt ist, muss die Webanwendung Vorkehrungen gegen einen Cookie-Überlauf treffen.<ref>Carsten Bormann: Panic-mode: A Disconnection-tolerant AJAX Library. (Memento vom 28. September 2007 im Internet Archive) O’Reilly Emerging Technology, März 2006</ref>

Funktionsweise

Es gibt zwei Möglichkeiten für die Übertragung, Zuweisung und Auswertung von Cookies durch eine Website:

  1. Übertragung in den Kopfzeilen (dem Header) von Anfragen und Antworten via HTTP. Cookies im Client entstehen, wenn bei dessen Zugriff auf einen Webserver neben anderen HTTP-Kopfzeilen in der Antwort des Servers zusätzlich eine Cookie-Zeile übertragen wird (siehe Aufbau).
  2. Außerdem kann ein Cookie lokal durch JavaScript oder weitere Skriptsprachen erzeugt werden. Das Skript befindet sich in der vom Server übermittelten Webseite.

Die lokalen Cookies derselben Domain – also nicht anderer Sites – können ausgelesen, verwertet und geändert werden. Damit können beispielsweise durch Javascript Informationen über die lokalen Benutzeraktivitäten eingearbeitet werden, die in der Sitzung ohne weiteren Serverkontakt angefallen waren. Mit dem nächsten Kontakt zur Website werden sie in den HTTP-Kopfzeilen auch dorthin übertragen.

Cookie-Informationen werden lokal im Browser gespeichert, üblicherweise in einer Cookie-Textdatei. Bei nachfolgenden weiteren Zugriffen auf den Webserver sucht der Client-Browser alle Cookies dieser Domain heraus, die zum Webserver und dem Verzeichnispfad des aktuellen Aufrufs passen. Diese Cookie-Daten werden im Header des HTTP-Zugriffs mit übertragen, sodass die Cookies nur an jenen Webserver zurückgehen dürfen, von dem sie einst auch stammten.

Ein Cookie kann beliebigen Text enthalten, kann also neben einer reinen Identifikation auch beliebige Einstellungen lokal speichern, jedoch sollte seine Länge 4 Kilobyte (4·1024 Byte) nicht überschreiten, um mit allen Browsern kompatibel zu bleiben. Die Cookies werden mit jeder übermittelten Datei übertragen, also auch mit Bilddateien oder jedem anderen Dateityp; dies gilt insbesondere für eingebettete Elemente wie Werbebanner, die von anderen Servern eingebunden werden als dem Ursprung einer angezeigten HTML-Datei. So kann eine einzelne Webseite zu mehreren Cookies führen, die von verschiedenen Servern kommen und an diese jeweils wieder zurückgeschickt werden.

Cookies werden ausschließlich vom Client verwaltet. Somit entscheidet der Client, ob beispielsweise ein Cookie gespeichert oder nach der vom Webserver gewünschten Lebensdauer wieder gelöscht wird. Allerdings können auch auf dem Server entsprechende Informationen gespeichert werden, um beispielsweise Statistiken über die Zahl der Aufrufe von Webseiten zu erzeugen.

Gängige Browser erlauben dem Nutzer, den Umgang mit Cookies mehr oder weniger festzulegen, z. B.:

  • Keine Cookies annehmen.
  • Nur Cookies des Servers der aufgerufenen Seite annehmen (keine Cookies von Drittservern wie bei Werbebannern).
  • Benutzer bei jedem Cookie fragen.
    • Hier kann dann meist zwischen „erlauben“ (bleibt), „für diese Sitzung erlauben“ (wird immer angenommen, aber nach dem Schließen des Browsers gelöscht) und „ablehnen“ (nicht akzeptieren) gewählt werden, wobei die gewählte Option gespeichert wird.
  • Alle Cookies beim Schließen des Browsers löschen („Sitzungs-Cookie“).

Dazu erlauben die Browser verwaltende Aktionen wie:

  • Daten im Cookie ansehen.
  • Einzelne oder alle Cookies löschen.

Schließlich kann der Benutzer die Inhalte von Cookies verändern, leeren oder löschen.

Ob ein Cookie angenommen oder abgelehnt wurde, kann die Server-Anwendung nur mit weiteren HTTP-Anfragen erkennen, da die Speicherung von Cookies vom Client nicht zurückgemeldet wird.

Gefahren

Tracking

Die Möglichkeit der eindeutigen Erkennung kann missbraucht werden. Cookies werden unter anderem dafür verwendet, Benutzerprofile über das Surfverhalten eines Benutzers zu erstellen. Ein Online-Shop kann diese Daten mit dem Namen des Kunden verknüpfen und zielgruppenorientierte Werbemails schicken. Jedoch kann der Online-Shop nur das Surfverhalten innerhalb seiner eigenen Webseite verfolgen.

Server, die nicht identisch mit dem Server der aufgerufenen Webpage sind, können etwa mit Bilddateien (Werbebanner oder auch Zählpixel) auch sogenannte Third-Party-Cookies (englisch für Cookies von Dritten) setzen; diese werden auch als „tracking cookies“ bezeichnet (englisch für Verfolgen). Gegebenenfalls kann so der Besuch unterschiedlicher Websites einem Benutzer zugeordnet werden. Es entsteht eine „serverübergreifende“ Sitzung. Daraus kann auf die Interessen des Besuchers geschlossen und Websites entsprechend angepasst („personalisiert“) werden. Bei einer Bestellung in einem Webshop etwa werden die angefallenen Daten einer konkreten Person zugeordnet.

Siehe auch: Abschnitt „Cookies“ zur Anonymität im Internet

Gefahr bei öffentlichen Internetzugängen

In Umgebungen, in denen sich mehrere Nutzer denselben Rechner teilen, etwa in Schulen oder Internet-Cafés, besteht die Gefahr, dass ein noch gültiger Sitzungs-Cookie vom nächsten Nutzer des Rechners verwendet wird, um die Sitzung seines Vorgängers fortzusetzen. Das kann verhindert werden, indem man grundsätzlich alle Cookies vor dem Beenden des Browsers löscht oder eine entsprechende Browser-Einstellung nutzt.

Erlauben oder Sperren

Ein Kompromiss zwischen den Vor- und Nachteilen von Cookies kann erzielt werden, indem man seinen Browser so konfiguriert, dass persistente Cookies nicht oder nur gegen Rückfrage zugelassen werden, was etwa die Erstellung von Benutzerprofilen erschwert, und Sitzungs-Cookies automatisch zugelassen werden, beispielsweise für Webeinkäufe, Passwörter. Außerdem bieten die meisten Browser die Möglichkeit, Cookies selektiv für bestimmte Domains zu erlauben bzw. zu sperren oder nach dem Surfen automatisch zu löschen, wie es automatisch bei Sitzungs-Cookies geschieht. Serverfremde Cookies lassen sich automatisch abweisen, über die ein Dritter, etwa ein Werbepartner der Internet-Seite, das eigene Verhalten über mehrere Server hinweg aufzeichnen könnte.

Browser bieten oft die Möglichkeit, Funktionen über kleine Zusatzprogramme (Add-ons) nachzurüsten. So ist es etwa bei Firefox mit einem bestimmten Add-On möglich, per Klick auf eine Schaltfläche Webseiten zu erlauben, Cookies zu speichern<ref>Firefox-Add-on Cookie Button</ref><ref>Firefox-Add-on Cookie Monster</ref> bzw. sogar selbst den Inhalt der Cookies zu manipulieren.<ref>Firefox-Add-on Add N Edit Cookies:

  • Add N Edit Cookies+
  • Edit Cookies</ref> Damit lassen sich Cookies generell deaktivieren sowie ausnahmsweise erlauben, falls die Website ohne Cookies nicht richtig funktioniert oder man sich bei einem Onlinedienst anmelden möchte. Andere Add-ons bieten einen Kompromiss zwischen der Browser-Option, alle Cookies beim Beenden des Browsers zu löschen bzw. sie nicht zu löschen, indem nur Cookies von bestimmten Internet-Domains per Whitelist behalten, alle anderen aber beim Beenden des Browsers gelöscht werden. So kann einerseits ungewünschte Verfolgung, andererseits aber das Verlorengehen von Informationen, welche dauerhaft gespeichert werden sollen, verhindert werden.

Siehe auch: Web Analytics

Aufbau

Ein Cookie besteht aus einem Namen und einem Wert. Bei der Definition eines Cookies können bzw. müssen zusätzlich ein oder mehrere Attribute angegeben werden. 

"Set-Cookie:" Name "=" Wert *( ";" Attribut)
"Cookie:" Name "=" Wert *( ";" Name "=" Wert)

Name und Wert sind Folgen von druckbaren US-ASCII-Zeichen, wobei einige Zeichen ausgeschlossen sind. Die Syntax von Name verwendet einen eingeschränkten Zeichensatz wie er auch bei anderen HTTP-Kopfzeilen in RFC 2616 verwendet wird.<ref>RFC 6265 Abschnitt 4.1.1 verweist auf die Spezifikation von token in RFC 2616 Abschnitt 2.2.</ref> Für Wert sind Semikolon, Komma, Leerraum-Zeichen und Backslash ausgeschlossen. Um beliebige Daten als Cookie-Wert zu speichern, kann eine Kodierung wie Base64 oder die URL-Kodierung mit %xx verwendet werden.

Das HttpOnly-Attribut soll den Zugriff auf Cookies mittels JavaScript verhindern. Auf Cookies, welche das Attribut HttpOnly besitzen, kann nicht per JavaScript zugegriffen werden. Dies stellt einen möglichen Schutz gegenüber XSS dar, sofern der jeweils genutzte Browser dieses Attribut unterstützt.

Beispiel

Szenario: Eine Webseite bietet eine Suchfunktion an, die sich an den zuletzt eingegebenen Suchbegriff erinnern kann, selbst wenn der Benutzer zwischenzeitlich den Browser beendet. Dieser Suchbegriff kann nicht auf dem Server gespeichert werden, da der Server dazu den Besucher eindeutig identifizieren müsste, und das geht mit reinem HTTP nicht. Deshalb soll der zuletzt eingegebene Suchbegriff vom Browser des Besuchers (in einem Cookie) gespeichert werden.

Wenn der Besucher die Suchfunktion zum ersten Mal aufruft (hier mit dem Suchbegriff „cookie aufbau“), schickt er folgende Anfrage an den Server: 

GET /cgi/suche.py?q=cookie+aufbau HTTP/1.0

Der Server antwortet mit dem Suchergebnis und bittet den Browser mittels des „Set-Cookie“ Feldes, sich den letzten Suchbegriff zu merken: <syntaxhighlight lang="text"> 

HTTP/1.0 200 OK
Set-Cookie: letzteSuche=Y29va2llIGF1ZmJhdQ==;
            expires=Tue, 29-Mar-2014 19:30:42 GMT;
            Max-Age=2592000;
            Path=/cgi/suche.py

</syntaxhighlight> (Normalerweise stehen alle Bestandteile des Cookies in einer einzigen Zeile. Zur besseren Lesbarkeit steht hier jedoch nur ein Attribut pro Zeile.)

Der Cookie hat die folgenden Bestandteile:

  • Nutzdaten (letzteSuche): Da die Nutzdaten nicht erlaubte Zeichen enthalten können (Leerzeichen in „cookie aufbau“), gibt der Server sie hier mit Base64 kodiert zurück.
  • Ablaufdatum (expires): Der Cookie wird nur in Anfragen mitgeschickt, die vor dem 29. März 2014 passieren.
  • Maximalalter (Max-Age): Der Cookie wird nur in den folgenden 30 Tagen mitgeschickt, später nicht mehr.
  • Teilbereich der Webseite (Path): Der Cookie wird nur an die Suchmaschine (/cgi/suche.py) geschickt, da alle anderen Teile der Webseite die Information nicht brauchen.

Entwicklungsgeschichte

Das Konzept wurde ursprünglich von Netscape Communications entwickelt und im 1994 veröffentlichten Netscape Navigator implementiert. Netscape veröffentlichte eine vorläufige Spezifikation auf ihrer Website. 1995 begann die IETF die Arbeit an einer Spezifikation, die als RFC standardisiert werden sollte. 1997 wurde die Spezifikation als RFC 2109 veröffentlicht und unterscheidet sich in einigen Details von der Netscape-Spezifikation. Die neue Spezifikation sollte sich inkrementell verbreiten, da der Netscape Navigator zu den Neuerungen aufwärtskompatibel war. Als bekannt wurde, dass die Cookie-Implementierung des Internet Explorers zur neuen Spezifikation inkompatibel war, begann die Arbeit an einer neuen Version. Diese wurde im Jahr 2000 als RFC 2965 veröffentlicht und verwendet neue HTTP-Kopfzeilen wie „Set-Cookie2“, um Inkompatibilitäten mit bestehenden Implementierungen zu vermeiden.<ref>David M. Kristol: „HTTP Cookies: Standards, Privacy, and Politics“, 9. Mai 2001. arXiv:cs.SE / 0105018.</ref>

Während die IETF RFC 2109 als „obsolete“ (veraltet) einstufte, fand RFC 2965 keine durchgehende Verbreitung. Opera unterstützte zusätzlich zum alten Format auch „Set-Cookie2“, Mozilla Firefox jedoch nicht.<ref>bugzilla.mozilla.org</ref> Im Jahr 2011 ersetzte RFC 6265 die beiden bisherigen RFCs. In RFC 6265 wurde die gängigste Funktionsweise spezifiziert und „Set-Cookie2“ als veraltet gekennzeichnet. Zusätzlich wurde das „HttpOnly“-Attribut spezifiziert, das im Jahr 2002 von Microsoft im Internet Explorer 6 eingeführt und von einigen Webbrowsern übernommen wurde.<ref>Übersicht HttpOnly, Geschichte und Referenz OWASP</ref>

Cookies nach Netscape-Spezifikation

"Set-Cookie:" Name "=" Wert *(";" Attribut)
"Cookie:" Name "=" Wert *(";" Name "=" Wert)

Name=Wert ist eine Folge von druckbaren US-ASCII-Zeichen ohne Semikolon, Komma und Leerraum-Zeichen. Falls eines dieser Zeichen in Name oder Wert vorkommen soll, muss es mit der URL-Kodierung %xx kodiert werden.

Folgende Attribute sind in der Spezifikation von Netscape definiert:<ref>Abschnitt 10.1 der RFC 2109 verweist darauf.</ref>

EXPIRES=dateValue (optional)
Verfallsdatum des Cookies im Format Wdy, DD-Mon-YY HH:MM:SS GMT.
Wenn kein Verfallsdatum angegeben wird, wird das Cookie beim Schließen des Browser gelöscht.
DOMAIN=domainName (optional)
Domainname, um die Gültigkeit des Cookies auf einen bestimmten Domainnamen zu beschränken. Hierbei muss der angegebene Domainname nur ein Suffix des Domainnamens sein, das heißt ein für DOMAIN=example.com bestimmtes Cookie ist gültig für example.com als auch darunterliegende Domains wie foo.example.com oder bar.quux.example.com. Falls dieses Attribut nicht angegeben wird, wird der aktuelle Domainname verwendet.
PATH=pathName (optional)
Pfadpräfix, um die Gültigkeit des Cookies auf einen bestimmten Pfad oder Pfadpräfix zu beschränken. Falls dieses Attribut nicht angegeben wird, wird der aktuelle Pfad verwendet.
SECURE (optional)
Cookie darf nur über eine sichere Verbindung (sprich HTTPS) an den Server gesendet werden.

Cookies nach RFC 2109

Der Unterschied der Spezifikation von RFC 2109 zu der von Netscape besteht insbesondere darin, dass als Wert nun auch Semikola, Kommata und Leerraum-Zeichen enthalten sein dürfen, die dann aber in Anführungszeichen gefasst werden müssen. Name darf aber nicht mehr mit einem $ beginnen, da diese für die Kennzeichnung von Attributen von Cookies in HTTP-Anfragen verwendet werden. 

"Set-Cookie:" Name "=" Wert *(";" Attribut)
"Cookie:" "$Version" "=" value 1*((";" | ",") Cookie)

Cookie ist hierbei ein Cookie, das neben dem Name-Wert-Paar auch noch die in Set-Cookie angegebenen und durch ein Semikolon voneinander getrennten Wertepaare für Path und Domain enthalten kann:

Name "=" Wert [";" "Path=" Pfad] [";" "Domain=" Domain]

Zusätzlich wurde das Expire-Attribut durch das Max-Age-Attribut ersetzt, das im Gegensatz zum Expire-Attributwert statt einem fixen Zeitpunkt die Gültigkeitsdauer nun in Sekunden angibt. Die Semantik von Domain wurde erweitert. Neu hinzugekommen sind die Attribute Comment und Version.

"Comment" "=" value (optional)
Kommentar zur näheren Beschreibung des Cookies
"Domain" "=" value (optional)
Domain oder Bestandteil des Domainnamens, für den der Cookie gilt. Falls diese Attribut nicht angegeben wird, wird der aktuelle Domainname verwendet. Falls diese Attribut jedoch angegeben wird, muss der Wert mit einem Punkt beginnen; falls nicht, wird der Punkt vom Client hinzugefügt.
"Max-Age" "=" value (optional)
Ablaufzeit in Sekunden – 0 für sofortige Löschung. Der Client darf den Cookie auch nach dieser Zeit benutzen, der Server kann sich also nicht darauf verlassen, dass der Cookie nach dieser Ablaufzeit gelöscht wird.
"Path" "=" value (optional)
wie in Netscapes Spezifikation
"Secure" (optional)
wie in Netscapes Spezifikation
"Version" "=" 1*DIGIT (notwendig)
Gibt die Cookie-Management-Spezifikation in einer Dezimalzahl an (immer 1 in dieser Spezifikation)

Cookies nach RFC 2965

Cookies nach RFC 2965 unterscheiden sich von denen nach Netscapes Spezifikation und nach RFC 2109 insbesondere dadurch, dass das Header-Feld Set-Cookie2 statt Set-Cookie heißt. 

"Set-Cookie2:" Name "=" Wert *(";" Attribute)
"Cookie:" "$Version" "=" value 1*((";" | ",") Cookie)

Daneben gibt es auch noch einige zusätzliche Attribute:

"Comment" "=" value (optional)
wie in RFC 2109
"CommentURL" "=" <"> http_URL <"> (optional)
URL unter welcher eine Beschreibung zur Funktionsweise zu finden ist (spezifiziert in RFC 2965)
"Discard" (optional)
Unbedingte Löschung des Cookies bei Beendigung des Webbrowsers (spezifiziert in RFC 2965, komplementiert Expires=0, Max-Age=0).
"Domain" "=" value (optional)
wie in RFC 2109
"Max-Age" "=" value (optional)
wie in RFC 2109
"Path" "=" value (optional)
wie in Netscapes Spezifikation
"Port" [ "=" <"> portlist <"> ] (optional)
Beschränkung des Ports auf den aktuell verwendeten oder auf eine Liste von Ports
"Secure" (optional)
wie in Netscapes Spezifikation
"Version" "=" 1*DIGIT (notwendig)
Gibt die Cookie-Management-Spezifikation in einer Dezimalzahl an (immer 1 in dieser Spezifikation)

Folgendes Beispiel zeigt eine Serverantwort nach RFC 2965. Der Server antwortet mit dem Suchergebnis und bittet den Browser mittels des „Set-Cookie2“ Feldes, sich den letzten Suchbegriff zu merken: <syntaxhighlight lang="text"> 

HTTP/1.0 200 OK
Set-Cookie2: letzteSuche="cookie aufbau";
             Max-Age=2592000;
             Path=/cgi/suche.py;
             Version="1";
             Port = 101;
             CommentURL = "http://example.org/docs/cookies/letzteSuche"

</syntaxhighlight>

Browseranforderungen

Nach RFC 6265 soll ein Browser die folgenden Mindestgrößen unterstützen:

  • Ein Cookie soll mindestens 4096 Bytes enthalten können.
  • Es sollen pro Domain mindestens 50 Cookies gespeichert werden können.
  • Es sollen insgesamt mindestens 3000 Cookies gespeichert werden können.

Die Spezifikation lässt zu, aber garantiert nicht, dass ein Browser mehr und größere Cookies verarbeiten kann.

Siehe auch

Weblinks

Einzelnachweise

<references />