C is for CookieDie wunderbare Welt von Isotopp

Samstag, 5. Februar 2011C is for Cookie

(Youtube DirektKeks)

Auf den vielfachen Wunsch einer einzelnen Dame hier der Erklärbar zum Thema Kekse für die Freunde

besagter Dame.

Eines der Hauptprobleme, das man lösen muß, wenn man Webanwendungen schreibt, ist die

Tatsache, daß man im wesentlichen Memento dreht.

Jedesmal, wenn man im Browser eine Seite aufruft, sieht der Webserver einen Request, bearbeitet

diesen und vergißt danach, was er getan hat. Es gibt nichts an einem Request, das man verwenden

kann, um den zweiten Requests sicher mit dem ersten Request zu verketten und sich an die Dinge zu

erinnern, die man im ersten Request getan hat.

Cookies und Sessions

Der erste und der zweite Request vom selben Browser sind nach Definition von HTTP für den

Webserver nicht als zusammengehörig erkennbar.

Man kann nicht den User­Agent des Browsers verwenden, weil es viele verschiedene Browser mitdemselben User­Agent geben kann. Man kann auch nicht die IP­Adresse verwenden: zum einen kannes vorkommen, daß mehr als ein Benutzer dieselbe IP­Adresse verwendet, weil es Rechner gibt, dievon mehreren Benutzern zeitgleich verwendet werden.

Zum anderen kann es vorkommen, daß Request 1 und Request 2 mit unterschiedlichen IP­Adressegesendet werden. Das ist oft der Fall, wenn ein Benutzer bei T­Online oder AOL ist oder wenn er Torverwendet. Dort geschieht dies regelmäßig wegen der Struktur der Proxyserver, die dort verwendetwerden. Bei Mobilbenutzern kann sich die IP­Adresse spontan ändern, wenn sie ihren Standortverändern, auch wenn das Netz versucht, dies zu verbergen. Und nach einer DSL­Zwangstrenung hatman natürlich auch eine neue IP­Adresse. Erstrecken sich Browser­Tätigkeiten über solche Intervalle,sieht man aufeinanderfolgende Requests desselben Benutzers von verschiedenen IP­Adresse.

Bei Memento löst man das Problem mit Tätowierungen, in Browsern verwendet man stattdessenCookies.

Cookie definieren: Der Webserver setzt mit dem Header Set­Cookie einen Cookie im Browser, hier

sessid=17.

Greift ein Browser das erste Mal auf eine Webanwendung zu, sendet er einen GET­Request mit demNamen der gewünschten Site im Host­Header und einigen weiteren Headerzeilen, die uns hier heutenicht interessieren sollen.

GET / HTTP/1.1

Host: www.shop.com

Connection: keep­alive

Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5User­Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en­US)AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.84 Safari/534.13Accept­Encoding: gzip,deflate,sdchAccept­Language: en­US,en;q=0.8Accept­Charset: ISO­8859­1,utf­8;q=0.7,*;q=0.3

Die Webanwendung reagiert mit einer Antwort, die einen Content­Type definiert (zum Beispiel text/htmlfür Webseiten) und die weitere Header enthalten kann. Einer dieser Header ist Set­Cookie. Das ist dieTätowierung, die unseren Browser von allen anderen Browsern unterscheidbar macht.

Set­Cookie: <name>=<value>[; expires=][; domain=][; path=][; secure][; httponly]

Set­Cookie definiert eine Variable mit dem Namen Name und dem Wert value. Es gibt Limits imBrowser für die Anzahl und Länge dieser Variablen pro Site und insgesamt. Mit der Definition einesCookies können weitere Einschränkungen festgelegt werden, die sagen wo und wie lange der Cookiegelten soll: Die Einschränkungen, die man festlegen kann, bestimmen an welche Domain der Cookiezurück übermittelt wird, wie lange er gelten soll, ob er für eine ganze Site oder nur einige Pfade auf derSite definiert sein soll, ob er nur mit SSL­Verschlüsselung übertragen werden soll und ob Javascript mitdem Cookie arbeiten darf.

Der Browser erhält diese Definition mit der Webseite, die ihm übermittelt wird, und während er dieWebseite darstellt, speichert er die Variable und den dazu gehörenden Wert ab.

Im Beispiel oben wird eine Variable mit dem Namen sessid definiert, die den Wert 17 bekommt. Es isteine zusätzliche Einschränkung definiert, die festlegt, daß diese Variable bei allen Zugriffen aufDomains mit der Endung .shop.com übermittelt werden soll. Da kein expires­Wert gesetzt ist, gilt dieVariable so lange wie der Browser läuft ­ andernfalls gälte sie so lange bis das gesetzte Datumverstrichen ist.

Mit jedem weiteren Zugriff (der die zusätzlichen Einschränkungen erfüllt) setzt er jetzt eine zusätzlicheHeaderzeile Cookie, in der er die Variable und ihren Wert zurück an den Server übermittelt.

Sobald ein Cookie gesetzt ist, übermittelt der Browser den Cookie bei jedem nachfolgenden

Requests, der die Bedingungen der Definition erfüllt. Hier wird also nun für jeden Request an einen

Host in der Domain shop.com die sessid=17 mitgesendet. Der Browser ist nun eindeutig

identifizierbar, solange die sessid eindeutig vergeben wird.

Unser Beispielcookie ist ein sogenannter Session­Cookie ­ er wird ohne ein expires definiert und dahernicht auf der Festplatte, sondern nur im Browser gespeichert. Beendet man den Browser, ist erverloren. Session­Cookies dienen dazu, aufeinanderfolgende Web­Requests ein und desselbenBrowsers miteinander zu verketten und erlauben es Webanwendungen, Zustand zu haben.

Zustand?Eine Anwendung ist ein Programm, das bestimmte Funktionen hat. Entgegen den Darstellungen in

gewissen Filmen liegen Programme gewöhnlich auf der Platte rum und tun gar nichts. Nur wenn siegestartet werden, wird ihr Code um etwas ergänzt ­ Variablen. Die Summe aller Variablen eines

Programmes ist sein Zustand.

Beide Dateien werden zur selben Zeit im selben Texteditor bearbeitet. Text,Cursorposition, Schriftart und Dateiname unterscheiden sich zwischenbeiden Dokumenten, d.h. diese Variablen haben in beiden Dokumenten

unterschiedliche Werte.

Ein Texteditor zum Beispiel hat viele Funktionen zum Bearbeiten von Texten.

Öffnet man ein neues Dokument, weiß der Textedit den Namen dieses Dokumentes ("untitled.txt"), die

Cursorposition (links oben) und den Text, der in dem Dokument enthalten ist sowie die aktuelle

Schriftart und ­farbe und noch viele andere Dinge mehr.

Ein zweites Dokument (hier: "Faust 3 ­ die Rückkehr.txt") enthält anderen Text, eine andere

Cursorposition, eine andere Schriftart und so weiter. Der Texteditor kann mehr als einen Text

bearbeiten, weil er für jedes Dokument seinen Zustand getrennt verwaltet.

Zwei Browser arbeiten mit demselben Webshop, einer hat die sessid=17, derandere die sessid=18. In zwei unterschiedlichen Datensätzen wird der

Warenkorb für jeden Browser verwaltet.

Genau so verhält es sich etwa bei einem Webshop. Auf dem Server liegt einmal der Code der

Webanwendung, mit Funktionen wie "Artikel anzeigen", "Warenkorb verwalten" und "abkassieren".

Aber natürlich muß man für jeden Benutzer des Webservers ­ womöglich viele hundert Personen

gleichzeitig ­ einen eigenen Warenkorb verwalten.

Man kann den Warenkorb selbst in den Cookie tun, aber das hat eine Reihe von Nachteilen. Zum

Beispiel ist die Größe und Lebensdauer des Warenkorbes dann von den Limits des Browsers

eingeschränkt. Zum anderen ist es dann so, daß die Daten des Warenkorbes bei jedem Request mit

übermittelt werden müssen. Das macht nicht nur jeden Request größer, sondern es macht auch bei

jedem Request einen Übergang von Daten aus der Gefahrenzone "nicht vertrauenswürdig" (irgendein

Browser im Internet) in die Gefahrenzone "vertrauenswürdig" (unsere Webanwendung) notwendig, und

führt so zu vielen unnötigen Prüfungen der Datenintegrität.

Normalerweise setzt man in einem Session­Cookie nur eine eindeutige Kennummer, die Session­ID.

Die Daten des Warenkorbes selber speichert man in einem Datensatz auf dem Server in einem Eintrag

mit genau dieser Kennung. Bekommen wir also einen Request von einem Browser mit der sessid=17,

laden wir den Datensatz für die sessid 17 und zeigen dem Kunden seinen Warenkorb an. Bekommenwir stattdessen einen Request für die sessid 18, laden wir diesen Warenkorb und zeigen diesen an.

Natürlich wird man nicht wirklich die Zahlen 17 und 18 verwenden, sondern sehr große, zufälliggewählte Zahlen wie etwa "a13bcf7a0b2fb6f9dfdebe2e0657c9e3" und"791c8d7234c56497fe23a593af3b1ab9". Sähe ein Hacker etwa eine sessid wie "17", würde er soforteinmal nachsehen, ob es "16" und "18" gibt und welche Daten da drin stecken. Bei"a13bcf7a0b2fb6f9dfdebe2e0657c9e3" sind nicht nur andere IDs schwer zu raten, sondern dergesamte Session­ID Raum ist dünn besetzt, d.h. die meisten anderen geratenen IDs gehören zu garkeiner Session.

Was wäre, wenn es keine Cookies gäbe?Man könnte Session­IDs auch anders als mit Cookies übermitteln. Statt des Requests

GET /shop.htmlHost: www.shop.comCookie: sessid=17

könnte man zum Beispiel auch die ID in die URL tun, also http://www.shop.com/shop.html?sessid=17laden:

GET /shop.html?sessid=17Host: www.shop.com

als Request senden. Oder man baut die ID in den Hostnamen ein: http://sessid17.shop.com/shop.htmlwäre die URL und der Request ist dann

GET /shop.htmlHost: sessid17.shop.com

Das Problem bei diesen anderen Verfahren ist, daß die Session­ID auf die eine oder andere WeiseBestandteil der URL wird. Dadurch gibt man die Session weiter, wenn man die URL an jemand andersper Cut & Paste per Mail, Skype oder sonstwie übermittelt. Ja, die URL wird sogar unter Umständenmit der Session­ID von Suchmaschinen archiviert ­ eine ganz schlechte Idee, denn so bekommt jederBenutzer der Suchmaschine dieselbe Session­ID, wenn er über die Suchmaschine in unseren Shopkommt.

Es gibt Mechanismen, die mit diesen Problemen fertig werden und die eine URL auch dann sichermachen können, wenn sie die Session­ID in der URL enthält, aber es ist viel besser, einenMechanismus zu verwenden, der das Problem schon im Ansatz vermeidet ­ und das ist genau dieIntention, die hinter der Erfindung von Cookies stand.

Cookies mit Datum und Auto­LoginEine weitere Anwendungsmöglichkeit von Cookies ist die Speicherung von Präferenzen imWebbrowser, sodaß eine Website bei folgenden Besuchen gleich so aussieht, wie vom Benutzervoreingestellt.

Dazu wird ein Cookie mit einem Expires­Wert gesendet, der dann womöglich erst sehr weit in derZukunft seinen Inhalt verliert. Dadurch wird der Cookie nicht mehr im Browser gespeichert, sondern aufder Festplatte in der Browserkonfiguration verewigt. Er steht auch nach einem Neustart noch zurVerfügung.

In dem Wert des Cookies werden die Benutzer­Voreinstellungen gespeichert ­ oder gar ein Login­Token, das den Benutzer eindeutig identifiziert, das schwer zu manipulieren ist und das auf dieseWeisen den Benutzer bei allen weiteren Besuchen auf der Site einloggt, ohne daß dieser noch einmaleinen Paßwort­Prompt zu sehen bekommt.

Set­Cookie: Login=kris­23b9404f78d90b881175bcfc5f57b61c;domain=.shop.com;expires=Sat, 01­Jan­2030 00:00:00 GMT;

path=/;

Die Site hat nun Methoden, mit denen sie die behauptete Identität ("kris") und den Authentizitätsbeweis(die Nummer da) zusammenführen kann und mit denen sie ableiten kann, daß kris wirklich malirgendwann in diesen Browser sein Paßwort getippt hat. Sie loggt kris nun automatisch ein ­ für dienächsten 20 Jahre.

Die dunkle Seite der Kekse ­ Präferenzen und TrackingGesetzte Cookies werden bei jedem Request übermittelt, der die im Set­Cookie gestelltenBedingungen erfüllt. Hat man also eine Webseite, die Bilder enthält, wird der Cookie auch bei allenRequests für Bilddateien mitgesendet.

Der Cookie­Mechanismus hat Einschränkungen, etwa bei der Domain­Bedingung. So kann man als"www.shop.com" zwar einen Cookie für "domain=.shop.com" setzen (also auch für "img.shop.com","static.shop.com" und so weiter), aber nicht für ".com" oder gar "." (alle Sites im Internet). Dieser etwasunbeholfene Mechanismus soll verhindern, daß man Cookies als Tracking­Mechanismus mißbrauchenkann. Denn wäre es legal, einen Cookie wie diesen zu senden:

Set­Cookie: ID=ee487f1423d28992ee285760875e2cb8;expires=Sat, 01­Jan­2030 00:00:00 GMT;domain=.;

dann hätte man dem Browser des Benutzers für die nächsten beiden Dekaden internet­weit eineeindeutige Kennung verpaßt und könnte diesen Benutzer bequem tracken.

Leider ist die Regel "zwei Punkte im Domainnamen" für viele Domains kaputt ("www.shop.co.uk" zumBeispiel ­ mit der Zwei­Punkte­Regel kann man Cookies für ganz .co.uk setzen), und so haben Browserin der Regel eine sehr lange und komplizierte Liste von Ausnahmefällen, die versucht, diesen defektenCookie­Sicherheitsmechanismus zu reparieren.

Tracking mit Cookies ­ und mit Javascript am Beispiel IVWWerbebanner­Generierer und Auflagenzähler umgehen das Problem sowieso auf anderen Wegen. Inden Seiten von web.de und bei vielen anderen Websites findet man zum Beispiel Code wie diesenhier:

<imgsrc="http://webdessl.ivwbox.de/cgi­bin/ivw/CP/264_PH;sc%3Dwebde/homepage"alt=""width="1" height="1"/>

Dieser Code lädt ein 1x1 Pixel großes Bild ­ das Bild ist ein transparentes GIF, also unsichtbar. DasBild wird aber nicht von der Domain web.de geladen, sondern von der Domain ivwbox.de.

Von dort bekommt man dann eine Antwort wie diese hier:

KK:~ kris$ curl ­D x 'http://webdessl.ivwbox.de/cgi­

bin/ivw/CP/264_PH;sc%3Dwebde/homepage'

KK:~ kris$ cat xHTTP/1.0 302 FOUNDDate: Sat, 05 Feb 2011 18:20:49 GMT...Set­Cookie: i00=01914d4d94fc5da00006; path=/; domain=.ivwbox.de; expires=Sunday,05­Feb­2012 18:20:44 GMT

Es wird also der Cookie i00 mit dem Wert 01914d4d94fc5da00006 definiert. Der Cookie hält ein Jahrlang und wird für die Domain ".ivwbox.de" gesetzt.

Immer wenn ich Seiten von web.de lade, wird das unsichtbare Zählpixel von webdessl.ivwbox.de mitgeladen und ich werde als Benutzer 01914d4d94fc5da00006 identifiziert. Die IVW kann so dieeindeutig unterscheidbaren Benutzer auf web.de zählen und so eine Werbe­Auflagenstärke für web.de

angeben, nach der sich der Werbepreis für Banner berechnet.

Das Pixel ist in jeder Seite von web.de, und bei einem geladenen Bild wird im HTTP­Header "Referer"übermittelt, in welcher Seite das Bild enthalten war. Dadurch kann man also leicht ermitteln, welcheKlickpfade der Benutzer 01914d4d94fc5da00006 auf web.de so typischerweise hat und was seineVerweildauer auf der Site ist. Verweildauern sind neben eindeutigen Benutzern wichtig, weil Sites mitlanger Verweildauer bessere Werbepreise bekommen (oder was glaubt Ihr, warum es auf FacebookSpiele und Chat gibt? Genau!).

Schließlich kann auch noch weitere Spielchen spielen, falls Javascript aktiviert ist. So findet man etwabei web.de vor dem Counterpixel den Code

<script type="text/javascript" src="http://uim.tifbs.net/js/4423.js"></script>

, der wiederum auf Umwegen die Datei http://uim.tifbs.net/js/global_4423_38.js nachlädt. Dort wirdan geeigneter Stelle ein Aufruf wie folgt gemacht:

this._loadPixel(this._replaceVariables('//pixelbox.uimserv.net/cgi­bin/webde/__TYPE__/__CODE__;sc%3D__SC__%26jsv%3D__JSV__%26scr%3D__SCR__%26flv%3D__FLV__%26vid%3D__VID__%26vct%3D__VCT__%26res%3D__RES__%26smv%3D__SMV__%26cona%3D__CONA__%26cost%3D__COST__?d%3D__D__%26r=__R__'));

Aus dem ganzen Drumherum geht hervor, dass die Texte der Form __NAME__ Platzhalter sind, dieWerten ersetzt werden, die zuvor von Javascript eingesammelt werden. FLV ist zum Beispiel dieinstallierte Version von Flash, RES die Bildschirmauflösung und so weiter. Die komplette Liste findetman in der Funktion _replaceVariables in der Javascript­Datei. Auf diese Weise bekommtpixelbox.uimserv.net, ein weiterer Zählservice, den web.de verwendet, nicht nur die Benutzeridentätper Cookie geliefert, sondern über den Pfad der URL und Javascript auch noch einen Haufen weitereInformation über den Rechner und seinen Benutzer.

Das Tracking der IVW ist jedoch ein wenig umfassender als man zunächt vermuten mag: Es wird janicht ohne Grund die Domain ivwbox.de statt web.de verwendet. Durch den Namen wird es möglich,den Cookie für ".ivwbox.de" zu setzen, also für alle Hosts in der Domain ivwbox.de.

Wenn ich also zeit.de aufrufe, wird ein Zählpixel von "zeitonl.ivwbox.de" geladen, wie man dort imHTML­Quelltext der Seite nachlesen kann. Dabei wird meine Identität 01914d4d94fc5da00006 vonweb.de ebenfalls wieder an .ivwbox.de übermittelt, und es wird dem Betreiber von ivwbox.de überzeitonl.ivwbox.de bekannt, daß der Benutzer 01914d4d94fc5da00006 neben web.de auch zeit.de nutzt.Dieses Wissen kann man natürlich gut gebrauchen, wenn man Werbebanner verkaufen will.

Über eine Verkettung von Daten könnte man das 01914d4d94fc5da00006­Pseudonym sogaraufdecken ­ wenn ich mich bei web.de einlogge, könnte man das Login kris@web.de mit der Kennung01914d4d94fc5da00006 zusammenführen und weiß so, daß kris@web.de die Zeit online liest.

Das Datenschutz­Nichtproblem ­ oder doch?web.de, zeit.de und ivwbox.de sind alles deutsche Rechner, die von deutschen Firmen betriebenwerden und man sagt mir, daß das IVW­Tracking mit dem deutschen und europäischenDatenschutzrecht konform ist. Google Anaytics macht dasselbe, aber deren Server stehen nicht inDeutschland und es ist keine deutsche Firma, und daher steht deutschen Datenschützern geradeSchaum vor dem Mund. Also wohlgemerkt, nicht wegen des Trackings, sondern weil es außerhalbihres Hoheitsgebietes stattfindet. Wenn es in Deutschland passierte wäre alles gut:

Websites dürfen IP­Adressen nicht ohne Erlaubnis des Nutzers in die USA übermitteln.Daher sei der Einsatz von Google Analytics in der jetzigen Form in aller Regel nachdeutschem Recht nicht erlaubt, argumentiert Dix beim Treffen der Google TechnologyUser Group Berlin.

Zusammenfassung

Zusammenfassung: Cookies sind eine gute Sache und sie zu blockieren verhindert sichere Sessions ­

und damit Funktionen wie Warenkörbe oder Logins. Cookies können auch verwendet werden, um

Benutzer zu tracken oder andere fragwürdige Dinge zu tun. Es ist jedoch nicht der Mechanismus

Cookie böse, sondern die jeweilige Anwendung ist zu untersuchen.

Wenn man eine Sicherheitseinstellung im Browser treffen möchte, dann sollte man Session­Cookies

(jene ohne Expires­Datum) erlauben und Cookies mit Verfallsdatum blockieren oder auf nachfragen

stellen.

Geschrieben von Kristian Köhntopp in Internet um 18:52 | Kommentare (10) | Trackbacks (0) | Eintrag bearbeiten

TrackbacksTrackback­URL für diesen Eintrag

Keine Trackbacks

KommentareAnsicht der Kommentare: (Linear | Verschachtelt)

Kann man nicht auch mit einigen Browsern Cookies von bestimmten Domains (also z.B ivwbox und

Konsorten) blocken und den Rest zulassen? Zugestanden etwas aufwendiger, aber wenn man unbedingt

will trotzdem eine Moeglichkeit.

Firefox kann das auf jeden Fall, bei anderen weiss ich es nicht genau.

#1 Armin (Link) am 05.02.2011 19:31

Siehe dazu die Diskussion von knarf weiter unten ­ NoScript, Cookie Monster und Ghostery.

#1.1 Kristian Köhntopp (Link) am 05.02.2011 20:08

In cookie­set.png steht domain=.shop.html ­ gemeint ist wohl .shop.com.

Und es heisst wirklich IP­Adresse (wie im Zitat) und nicht IP­Nummer. Und diese ganzen Scharf­S­

Schreibfehler, schlimm! :)

Ansonsten zum Thema: NoScript, Cookie Monster und Ghostery sind ein tolles Team im Firefox. Nen

ivwbox­Cookie jubelt mir so schnell keiner unter.

#2 knarf (Link) am 05.02.2011 19:58

Danke für den Hinweis, ich habe das Bild überarbeitet.

#2.1 Kristian Köhntopp (Link) am 05.02.2011 20:06

Schöner Beitrag. Ich erinnere mich, dass Du dieses in der Dienstagsgruppe in Kiel schon mal erklärt

hattest und es mir bis dahin auch nicht klar war.

#3 Martin Schiedt (Link) am 05.02.2011 20:10

Eine Freundin fragte mich nach dem Artikel über Cookies für ihre Freunde, nachdem sie mit den

anderen Erklärbären von mir gute Erfolge hatte. Ich dachte, ich hätte einen Artikel zum Them cookie

schon im Blog ­ dem war nicht so.

Also habe ich schnell ein paar Bilder gemalt und was drumrum getextet. Ich hoffe, es nützt wem.

#3.1 Kristian Köhntopp (Link) am 05.02.2011 20:14

Es nützt. Eine kurzweilige Erklärung mit plastischen Beispielen abzugeben ist aufwendig, wenn

man nicht talentiert ist oder im Erklären geübt. Deshalb: danke.

#3.1.1 Sil53r Surf3r am 06.02.2011 14:09

Sehr guter Artikel!

Den letzten Satz würde ich allerdings noch ergänzen: Es sollten nur Cookies der eigentlich besuchten

Website und keine von "Drittanbietern" angenommen werden. Die meisten aktuellen Browser bieten

diese Einstellmöglichkeit.

#4 SailorMoon am 06.02.2011 08:18

Super Erklärung, Danke:)

#5 FreundDerFreundin am 07.02.2011 08:57

Und wer seine Ruhe von trackenden Cookies etc. haben will, verwendet einfach Adblock (Plus) und eine

entspr. Blocking­Liste (oder macht das einfach selbst; das Google­Tracking wie auch das von IVW uvam.

ist bei mir von Haus aus auf der ABP­Abschussliste ;)).

cu, w0lf.

#6 fwolf (Link) am 07.02.2011 23:29(Kommentare für diesen Eintrag nicht mehr zulassen)

Kommentar schreibenName

E­Mail

Homepage

Antwort zu [ Ursprung ]

Kommentar

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort

unterstrichen werden.

BBCode­Formatierung erlaubt Daten merken?

Kommentar abschicken Vorschau