Performance Tracking

Datengesteuert

cookie production in a factory

Was der Online-Marketer wissen sollte. Teil 2: So funktionieren Cookies (HTTP Header)

| Keine Kommentare

Interessantester Aspekt der HTTP Header ist die Übermittlung von Cookies. Sie sind die größten “Player” im Tracking des Online Marketing und dessen Geldflüsse. HTTP Header wurden bereits in Teil 1 erwähnt. Dieser zweite Teil der Serie “Was der Online-Marketer wissen sollte” baut darauf auf.

cookie production in a factory

Das sind HTTP Header

Zur Verdeutlichung zunächst die HTTP Response des Beispiels aus Teil Eins:

HTTP\1.1 200 OK
Date: Mon, 12 Mar 2012 11:07:10 GMT
Cache-Control: no-store
Pragma: no-cache
Server: Apache
Content-Length: 83
Content-Type: text/plain
Connection: close

{Datei Inhalt}

Direkt folgend der Request- (GET /sonstiges/http-test.txt) oder Response-Line (HTTP\1.1 200 OK) übermitteln die HTTP Header Meta-Informationen zum Request oder zur Response und folgen einem strikten Format:

Am Beispiel von performancetracking.de/sonstiges/http-test.txt also:

Date
Das Datum und Uhrzeit der Antwort des Servers.
Cache-Control & Pragma
weisen darauf hin, dass diese Seite nicht gecached oder zwischengespeichert werden soll.
Server
Apache – Name der Serversoftware. Ein Server ist ein “normaler” Computer. Auf Diesem laufen unterschiedliche Programme (Datenbank, Mailserver, Backups, …). Eines davon antwortet auf HTTP Anfragen – in diesem Fall der Apache.
Content-Length
83 – Die Anzahl der Bytes, die {Datei Inhalt} umfasst. Hat der Browser diese Anzahl von Bytes empfangen, kann er sicher sein die gesendete Datei vollständig empfangen zu haben.
Content-Type
text/plain – Was für eine Art von Datei wird übermittelt? Andere Formate wären z.B. text/html, text/javascript, application/pdf, image/jpeg.
Connection
close – Wie in der Beispiel-Anfrage angefordert, wird hier das Schließen/Beenden der Verbindung nach dieser Antwort bestätigt. Die häufiger vertretene Alternative ist Connection: Keep-Alive, da i.d.R. mehrere Dateien – vom HTML referenzierte Bilder und Stylesheets (CSS) – geladen werden und so die Verbindung nicht immer wieder auf und abgebaut werden muss.

Cookies sind HTTP Header

Cookies sind nichts weiter als ein HTTP Header: Cookie: cookie-name=cookie-wert;cookie2-name=cookie2-wert

Dabei ist Cookie der Name des Headers und alle zu übermittelnden Cookies werden in einem Headerwert zusammengefasst: cookie-name=cookie-wert;cookie2-name=cookie2-wert.

Je mehr Cookies übertragen werden, um so größer wird also auch der HTTP Cookie Header, was sich direkt auf die Seitenladegeschwindigkeit auswirkt.

Da das HTTP ein zustandsloses Protokoll ist, sind Cookies zwingend erforderlich, um während eines Besuches eine Sitzung (en: Session) und deren eindeutigen Merkmalen (wer ist angemeldet, welche Produkte sind im Warenkorb) nachzuhalten. Eine Anfrage auf http://shop.example.org/warenkorb wäre ohne Cookies zwischen unterschiedlichen Nutzern nicht zu unterscheiden.

So werden Cookies gesetzt

Legt Kunde Schmitz auf http://shop.example.org z.b. das Produkt ‘Füllfederhalter’ in den Warenkorb, könnte der Server folgenden Cookie setzen: warenkorb=Füllfederhalter. Hierzu müsste der Server folgenden HTTP Header senden:

Set-Cookie: warenkorb=Füllfederhalter;
Abbildung des Datenflusses

Ein Cookie wird, während er gültig ist, bei weiteren Anfragen stets and den Herkunftsserver gesendet.

Cookies auslesen

Bei allen folgenden Requests des Browsers, z.B. wenn Schmitz eine andere Produktseite aufruft, sendet Schmitz’s Browser folgenden HTTP Cookie Header:

GET /tinte HTTP/1.1
Host: shop.example.org
Cookie: warenkorb=Füllfederhalter
Connection: Keep-Alive

Soll ein zweites Produkt z.B. ‘Tinte’ hinzugefügt werden, könnte der Server mit diesem Set-Cookie Header den Warenkorb Cookie aktualisieren/überschreiben:

Set-Cookie: warenkorb=Füllfederhalter|tinte;

Denn durch die Anfrage ist das erste Produkt ‘Füllfederhalter’ bereits bekannt. Bei allen folgenden Requests des Browsers sendet Schmitz’s Browser dann folgenden HTTP Cookie Header:

GET /bestellweg HTTP/1.1
Host: shop.example.org
Cookie: warenkorb=Füllfederhalter|tinte
Connection: Keep-Alive

Cookies richtig einsetzen

Ist Schmitz bereits Kunde und meldet sich im Shop an, könnte ein weiterer Cookie kunde=schmitz gesetzt werden. Als HTTP Request Header: Cookie: warenkorb=Füllfederhalter|tinte;kunde=schmitz

Wird über den kunde Cookie der Kunde Schmitz identifiziert, dann ist der Warenkorb Cookie überflüssig: Im Gegensatz zum Warenkorb-Cookie des Browsers, wodurch sich effektiv der Browser den Warenkorb-Inhalt merkt, könnte der Server Diesen von Schmitz speichern. Weiterer Vorteil: Meldet sich Schmitz über einen anderen Computer oder Browser an, oder löscht Schmitz seine Cookies, kann der Warenkorb dennoch wieder hergestellt werden, sobald sich Schmitz anmeldet.

Sicherheitsrisiken (Session Hijacking)

Würde tatsächlich ein Cookie kunde=schmitz eingesetzt werden, würde dies ein enormes Sicherheitsrisiko darstellen.

Warum? Cookies können nicht ausschließlich über den Set-Cookie Header eines Servers erstellt werden. Ein Angreifer müsste lediglich seinen Browser dazu bringen einen “unechten” kunde=schmitz Cookie bei Anfragen an shop.example.org mitzusenden! Das ist über entsprechende Browserfunktionen oder Plugins ohne weitere Umstände möglich. Der Server würde in diesem Fall davon ausgehen, dass die Anfrage vom Kunden Schmitz kommt. Neben den Warenkorbdaten würde dem Angreifer so vielleicht auch Zugriff auf die hinterlegten Kontoverbindungen gewähren.

Lösung: Eigentlich ziemlich Banal: Im Cookie wird nicht der Kundenname sondern eine möglichst große Zufallszahl gespeichert welche die Aktuelles Sitzung Identifiziert – die Session ID. So wird es für den Angreifer erschwert den Wert des kunde bzw. jetzt sid (o.Ä.) Cookies zu erraten.

Nichts desto trotz, ist es nicht Unmöglich den Wert dieser Session ID zu Bekommen und eine bekannte Hacking methode bekannt als “Session Hijacking”. Um etwas paranoia vorzubeugen: wird z.B. HTTPS anstelle von HTTP verwendet, wird der gesammte Text und Datenverkehr den HTTP beschreibt nach Verschlüsselt – das ‘s’ steht hierbei für ‘Secure’. So kann zumindest jemand im selben W-LAN (Schon mal in einem öffentlich Starbucks W-LAN eMails abgerufen?) den HTTP Verkehr nicht einfach mitlesen. Mit HTTP geht das ohne weiteres. Es gibt sogar ein proof-of-Concept Plugin was das Session-Hijacking für den Firefox sehr nutzerfreundlich macht. Plugin einschalten und es schneidet den Datenverkehr des aktuellen W-LANs mit. Wird eine Anfrage an eine der Vorgefertigten Seiten identifiziert (z.b. Facebook, Twitter, WordPress…) werden die entsprechenden Cookie Daten (sid oder loginUser, …) extrahiert und für den eigenen Firefox Übernommen. Wird dann die entsprechende Seite angesurft, denkt der Server die Entsprechende person sei eingelogged. Es wurde die identity übernommen und alle Funktionen stehen bereit! Daraufhin haben Facebook, Twitter, Google und viele weitere eine HTTPS option für Nutzer bereitgestellt oder gar als standard implementier.

Schematische Darstellung des Session Hijacking

Cookie Daten können über unterschiedlichste Wege erspäht werden.

Cookies zur Provisionierung

Aufgrund von Sicherheitsrisiken sind Cookies immer an eine Domäne gekoppelt. Wird ein Cookie von example.org gesetzt, sendet der Browser diesen Cookie auch nur an example.org und nicht an google.com oder andere Server. Setzt ein Server einen Cookie, können zwar eine andere Domäne angegeben werden, doch Browser akzeptieren nur die im Request genannte Domäne oder eine Sub/übergeordnete Domäne (shop.example.org kann cookies für example.org setzten. example.org auch für shop.example.org nicht aber noch-weiter-weg.shop.example.org).

Soll also ein Affiliate Cookie z.B. vom Zanox Netzwerk gesetzt oder gelesen werden, muss zwangsläufig die Adresse ad.zanox.com irgendwie aufgerufen werden. Hierzu bindet der Publisher das Werbemitel mit dem link http://ad.zanox.com/ppc/?21229731C982638502S12798091T ein. Der Server antwortet mit:

HTTP/1.1 302 Moved Temporarily
Location: http://shop.example.org/?zanpid=1616130346687214593
Set-Cookie: zcc=5C268571S1616130399687214593T0I1616130342387214593C10561; expires=Sun, 17-Mar-2013 16:05:00 GMT; path=/
[…]
Location
Wohin weitergeleitet werden soll (die Merchant-Seite). Der zanpid Parameter wäre nicht Zwingend erforderlich. Er dient lediglich als Hinweis für den Merchant wie der Nutzer auf die Seite gefunden hat. Mehr zu URL Parametern kommt in Teil 3.
Set-Cookie
Die Kerninformation fürs Affiliate Marketing!

  • zcc=5C268571S1616130399687214593T0I1616130342387214593C10561; Das Äquivalent des oben gennanten kunde oder sid. Hier wird jedoch nicht eine Warenkorb, sondern die Information über welchen Publisher die Weiterleitung zum Merchant erfolgt. Publisher und Werbemittel werden anhand des URL parameters 21229731C982638502S12798091T identifiziert.
  • expires=Sun, 17-Mar-2013 16:05:00 GMT; Der Cookie soll bis zu diesem Datum bestehen bleiben.
  • path=/ Ähnlich wie bei der Domäne lässt sich ein Pfad definieren, unterdem der Cookie gültig ist.

Im Bestellprozess des Merchants wird dann der Zanox Pixel Aufgerufen. Durch den zcc=5C26…561 Cookie wird der konvertierte Kunde Identifiziert. Der Zanox Server kann anhand Dieser Kunden ID dann den zu provisionierenden Publisher Identifizieren.

Autor: Lukas Grebe

Lukas Grebe ist als Webanalyst der Sparhandy GmbH, eines der führenden E-Commerce Unternehmen im Bereich Telekommunikation, für das Gesamtportfolio der digitalen Datenanalyse verantwortlich.

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.