Stemel und HTTP-Cookie: Unterschied zwischen den Seiten

Inhalt gelöscht Inhalt hinzugefügt

Inline

Version vom 28. Juli 2011, 09:14 Uhr

Ein HTTP-Cookie, auch Browser-Cookie genannt ([ˈkʊki]; engl. „Plätzchen“, „Keks“), ist eine spezielle Form der allgemeinen Magic Cookies. Es wird von einem Webserver zu einem Browser gesendet oder auf dem Client erzeugt und dort dauerhaft gespeichert. Bei weiteren Zugriffen sendet der Client die Cookie-Informationen im Hypertext-Transfer-Protocol-Header an den Server. Dadurch erleichtern Cookies die Anpassung von Webseiten auf Clienteinstellungen und Benutzerverhalten und ermöglichen den Aufbau von Sitzungen. Dieses Konzept wurde ursprünglich von Netscape entwickelt und in RFC 2109 spezifiziert.

Funktionsweise

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

Übertragung in den Kopfzeilen (Header) von Anfragen und -Antworten via HTTP. Cookies entstehen, wenn bei einem Zugriff auf einen Webserver neben anderen HTTP-Kopfzeilen in der Antwort zusätzlich eine Cookie-Zeile übertragen wird (siehe Aufbau). Die Cookie-Information wird auf dem Server generiert und ausgewertet.
Zusätzlich kann ein Cookie auch zunächst lokal generiert werden, nämlich durch JavaScript, Java oder weitere Skriptsprachen. Die lokal vorgefundenen Cookies derselben Domain können ausgelesen, verwertet und geändert werden. Damit können 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 auch dorthin übertragen.

Diese Cookie-Informationen werden dann lokal auf dem Endgerät gespeichert, üblicherweise in einer Cookie-Textdatei. Bei nachfolgenden weiteren Zugriffen auf den Webserver wird der Client-Browser alle Cookies dieser Datei heraussuchen, die zum Webserver und dem Verzeichnispfad des aktuellen Aufrufs passen, und diese Cookie-Daten im Header des HTTP-Zugriffs mit zurückschicken, womit die Cookies jeweils 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; mit einer Anfrage des Browsers werden alle den Server betreffenden Cookies gesendet.

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.

Gängige Browser erlauben dem Nutzer meist nur eingeschränkte Einstellungen zum Umgang des Clients mit Cookies, 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 einige Browser verwaltende Aktionen wie:

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

Schließlich ist dem Benutzer mit Hilfsmitteln (Browser-Plugin) oder auch nur einem einfachen Editor die Veränderung der Inhalte von Cookies möglich.

Ob ein Cookie angenommen oder abgelehnt wurde, muss die Server-Anwendung in weiteren HTTP-Anfragen erkennen, da das vom Client nicht direkt zurückgemeldet wird.

Der Server kann ein Cookie durch Überschreiben mit leeren Daten löschen.

Verwendung

Eine typische Anwendung von Cookies ist das Speichern persönlicher Einstellungen auf Websites, zum Beispiel in Foren. Es ist eine Möglichkeit, eine Webseite zu besuchen, ohne jedes Mal die Einstellungen erneut vornehmen zu müssen.

Mit Cookies können auch Sitzungen realisiert werden. Das HTTP ist per Definition ein zustandsloses Protokoll, daher ist für den Webserver jeder Zugriff völlig unabhängig von allen anderen. Eine Webanwendung, die sich über längere Zeit hinzieht, muss mit Zusätzen auf der Anwendungschicht (im Browser) arbeiten, um den Teilnehmer über mehrere Zugriffe hinweg identifizieren zu können. Dazu wird in einem Cookie vom Server eine eindeutige Session-ID gespeichert, um genau diesen Client bei weiteren Aufrufen wieder zu erkennen und damit nicht bei jedem Aufruf einer Unterseite das Passwort erneut eingegeben werden muss.

Auch Online-Shops können Cookies verwenden, um virtuelle Einkaufskörbe zu ermöglichen. Der Kunde kann damit Artikel in den Einkaufskorb legen und sich weiter auf der Website umschauen, um danach die Artikel zusammen zu kaufen. Die Artikel-Kennungen werden in einem Cookie gespeichert und erst bei der Bestellung 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 verloren gehen, können Cookies zur Zwischenspeicherung eingesetzt werden. Sie werden dann bei Wiedererrichtung der Verbindung automatisch zum Server geschickt. 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.^[1]

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 so genannte „serverfremde“ Cookies 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.

Denkbar wäre ein Missbrauch bei einer Kooperation zwischen dem Webshop und dem Werbeunternehmen; diese kann verhindert werden durch eine entsprechende Browser-Einstellung, die nur Cookies des Servers der aufgerufenen Seite (Webshop) annimmt, nicht die der fremden Server, die die Werbung einblenden. Wirbt der Webshop allerdings selber, könnte diese zielgerichtete Werbung so nicht verhindert werden. Amazon wertet bekanntlich die Bestellhistorien der Käufer systematisch aus, um auch unbekannten Besuchern konkrete Vorschläge zu machen.

Gefahr bei öffentlichen Internetzugängen

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

Weitere Gefahren

Noch nicht zu übersehen sind die Gefahren, die dadurch entstehen, dass Großunternehmen deren Dienste praktisch jedermann ständig nutzt, sich vorbehalten, die dadurch entstehenden Daten auf unbegrenzte Zeit zu bevorraten und auszuwerten. Um Daten über das Nutzerverhalten zu sammeln, ist man nicht auf Cookies angewiesen. Das Problem ist also wesentlich allgemeinerer Natur.

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. Auch ist es möglich, serverfremde Cookies automatisch abzuweisen, über die ein Dritter, etwa ein Werbepartner der Internet-Seite, das eigene Verhalten über mehrere Server hinweg aufzeichnen könnte.

Es ist auch möglich, Cookies automatisch beim Schließen des Browsers löschen zu lassen. Damit werden Probleme mit Mehrbenutzersystemen weitgehend vermieden und die Überwachung des Benutzers durch Cookies wird zumindest eingeschränkt. Zugleich verzichtet der Benutzer damit auf die Vorteile persistenter Cookies: Er muss sich bei der nächsten Sitzung überall wieder neu einloggen. Das führt aber zu neuen Sicherheitsproblemen, denn die Benutzer neigen dazu, überall dasselbe Passwort zu verwenden, da sich niemand eine Vielzahl von Passwörtern merken will. Selbst die Benutzung von mehreren Passwörtern führt dazu, dass der Benutzer gegebenenfalls alle ausprobiert und sie damit gegenüber der betreffenden Webseite preisgibt.

Des Weiteren bieten moderne Browser 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^[2]^[3]^[4] bzw. sogar selbst den Inhalt der Cookies zu manipulieren.^[5] Dadurch kann man Cookies generell deaktiviert lassen kann und sie nur dann erlauben, wenn die Internetseite nicht richtig funktioniert oder man sich bei einem Onlinedienst anmelden will.

Siehe auch: Web Analytics

Aufbau

Ein Cookie besteht aus einem Namen und einem Wert. Bei der Definition eines Cookies können beziehungsweise müssen zusätzlich ein oder mehrerer Attribute angegeben werden. Je nach Spezifikation (Netscape, RFC 2109, RFC 2965) gibt es unterschiedliche Vorgaben zu Namen, Wert und Attributen des Cookies.

Cookie nach Netscape

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

Name=Wert ist eine Folge von druckbaren US-ASCII-Zeichen ohne Semikolon, Komma und Weißraum-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:

EXPIRES=dateValue (optional): Verfallsdatum des Cookies im Format Wdy, DD-Mon-YY HH:MM:SS GMT.
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 diese Attribut nicht angegeben wird, wird der aktuelle Domainname verwendet.
PATH=pathName (optional): Pfadpräfix, um die Gültigkeit des Cookies auf einen bestimmten Pfad/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) zurückgeschickt werden.

Cookie nach RFC 2109

Der Unterschied der Spezifikation von RFC 2109 zu der von Netscape besteht insbesondere darin, dass als Wert nun auch Werte Semikolons, Kommas und Weißraum-Zeichen enthalten 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 (derzeit immer 1)

Cookie 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 paar 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 (derzeit immer 1)

Zusätzlich zu diesen Attributen gibt es noch das HttpOnly-Attribut, das den Zugriff auf Cookies mittels JavaScript verhindern soll und von fast allen Browsern unterstützt wird. Ältere Browser mögen dies nicht unbedingt unterstützen. Diese Erweiterung wurde wohl ursprünglich von Microsoft im Internet Explorer 6 eingeführt. Auf Cookies, welche das Attribut HttpOnly besitzen, kann von den meisten Browsern nicht per JavaScript zugegriffen werden. Dies stellt einen möglichen Schutz gegenüber XSS dar, sofern der jeweils genutzte Browser dieses Attribut unterstützt (Diese Erweiterung ist kein Bestandteil der verfügbaren RFCs).

Obwohl RFC 2109 vollständig durch RFC 2965 ersetzt wurde, unterstützen die meisten Webbrowser und Server noch die HTTP-Cookie Spezifikation nach RFC 2109. Auch das eigentlich nicht im Standard verwendete Expires wird weiterhin unterstützt. RFC 2965 Unterstützung gibt es in den meisten modernen Webbrowsern. Allerdings gibt es auch hier Unterschiede in der Vollständigkeit der Unterstützung, vor allem HttpOnly betreffend^[6].

Funktionsweise – ein 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 (nach RFC 2109):

HTTP/1.0 200 OK
Set-Cookie: letzteSuche="cookie aufbau";
            expires=Tue, 29-Mar-2005 19:30:42 GMT;
            Max-Age=2592000;
            Path=/cgi/suche.py;
            Version="1"

(Normalerweise stehen alle Eigenschaften des Cookies in einer einzigen Zeile. Zur besseren Lesbarkeit steht hier jedoch nur ein Attribut pro Zeile.) Der Cookie hat die folgenden Eigenschaften:

Nutzdaten (letzteSuche): Der letzte Suchbegriff
Ablaufdatum (expires): Der Cookie wird nur in Anfragen mitgeschickt, die vor dem 29. März 2005 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.

Nach RFC 2965 könnte die oben gezeigte Antwort des Servers wie folgt aussehen:

Der Server antwortet mit dem Suchergebnis und bittet den Browser mittels des „Set-Cookie2“ Feldes, sich den letzten Suchbegriff zu merken (nach RFC 2965):

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"

Browseranforderungen

Nach RFC 2965 soll ein Browser Folgendes unterstützen:

Es sollen insgesamt mindestens 300 Cookies gespeichert werden können.
Es sollen pro Domain mindestens 20 Cookies gespeichert werden können.
Ein Cookie soll mindestens 4096 Bytes enthalten können.

Manche Browser können mehr und größere Cookies verarbeiten, garantiert ist dies aber nicht. Umgekehrt halten sich aber auch nicht alle Browser an alle Anforderungen.

Siehe auch

Weblinks

cookiecentral.com – umfangreiche Seite über Cookies (englisch)
Schwerpunkt Cookies - bei www.verbraucher-sicher-online.de
Ursprüngliche Cookie-Spezifikation von Netscape
RFC 2965 HTTP State Management Mechanism – Festlegung des Cookies-Standards
Super-Cookies (DOM Storage)

Einzelnachweise

↑ Carsten Bormann: Panic-mode: A Disconnection-tolerant AJAX Library O’Reilly Emerging Technology, März 2006
↑ Firefox-Add-on CookieSafe
↑ Firefox-Add-on Cookie Button
↑ Firefox-Add-on Cookie Monster
↑
Firefox-Add-on Add N Edit Cookies:
- Add N Edit Cookies+
- Edit Cookies
↑ OWASP: Übersicht HttpOnly, Geschichte und Referenz

Vorlage:Link FA

[1] Carsten Bormann: Panic-mode: A Disconnection-tolerant AJAX Library O’Reilly Emerging Technology, März 2006

[2] Firefox-Add-on CookieSafe

[3] Firefox-Add-on Cookie Button

[4] Firefox-Add-on Cookie Monster

[5] Firefox-Add-on Add N Edit Cookies:
Add N Edit Cookies+

Edit Cookies

[6] Add N Edit Cookies+

[7] Edit Cookies

[6] OWASP: Übersicht HttpOnly, Geschichte und Referenz

[1]

[2]

[3]

[4]

[5]

[6]