„Making search more secure: Accessing search query data in Google Analytics“ lautet die Überschrift in einem aktuellen Blogbeitrag im offiziellen Google Analytics (GA) Blog. More secure? I don’t think so! Wie Google Anforderungen an sichere Verbindungen im Internet missinterpretiert, und alle anderen Größen im Internet übrigens auch.
Im Google Analytics Blog wurde am 18. Oktober 2011 eine Ankündigung gemacht, die vielen Experten und GA-Nutzern den Tag etwas versauern durfte. Alle Informationen über den Suchbegriff werden beim Anklicken eines Suchergebnisses in Googles HTTPS-Modus nicht mehr mitgeschickt. Das „referrer“-Tag im HTTP Request wird mit einem „not provided“ an der Stelle ausgestattet, wo sich früher das Keyword befand, das man so schön in Web Analytics Software auswerten konnte. Eine Informationsquelle versiegt und man meint sich darüber empören zu müssen im ersten Moment.
Wäre da nicht das RFC 2616 Protokoll der Internet Engineering Task Force, die maßgebliche Standards wie das HyperTextTransferProtocoll (HTTP), TransmissionControlProtocol (TCP) und InternetProtocol (IP) bestimmt. Das RFC 2616 besagt: „Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol“. Ein Satz, den manche große Webseiten noch nicht so ganz verinnerlicht haben.
In unserem Fall ist der Client der Besucher bzw. dessen Browser, der Google unter der SSL Verbindung https://www.google.com/ ansurft. Klickt er auf ein Suchergebnis, dessen Ziel-URL nicht ebenfalls eine SSL verschlüsselte Seite ist, so sollte laut oben zitiertem Protokoll keinerlei Information über den Referer (in diesem Fall www.google.com) mitgeschickt werden. Diese Einstellung treffen z. B. Firefox Benutzer vollautomatisch, da Firefox in der aktuellen Version 8.0.1 in der Konfigurationsdatei die Variablen entsprechend voreinstellt.
Firefox Config
Doch diese Einstellung wird elegant von manchen großen Websites umgangen, dazu gehört Google, Facebook und auch Twitter. In allen Fällen wird ein Klick auf einen Link erst vorgetäuscht, dank JavaScript über verschiedene URLs mehrere Weiterleitungen erzeugt und auf das eigentliche Ziel verwiesen. Diese Schleifen dreht man sehr gerne bei Verlinkungen, insbesondere z.B. bei affiliate Links, um Informationen zu sammeln und evtl. Cookies zu setzen.
Im Detail betrachten wir dazu exemplarisch Google.de und deren Suchergebnisseite. Wir rufen https://www.google.de/search?q=test auf und klicken auf das erste Suchergebnis http://www.test.de. Zu erwarten ist, dass wir als nächstes einen HTTP GET Request an den entsprechenden DNS senden für test.de – doch die Rechnung wurde ohne Google gemacht. Elegant wird nämlich über JavaScript vorher noch eine unsichere Verbindung über HTTP GET „/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDgQFjAA&url=http%3A%2F%2Fwww.test.de%2F&ei=DWvwTtS0CYuLswaNhZXZDw&usg=AFQjCNExSl_aJh-irODpoIla40aIiDVM-w&sig2=m74yiQYMt6l1N7JllreP6A HTTP/1.1“ abgerufen, ohne den HTTPS-Referrer.
Im Anschluss dazu wird nun http://www.test.de/ aufgerufen, mit dem Referer: „http://www.google.de/[…]“. Obwohl dem Benutzer angezeigt wird, sich auf einer verschlüsselten HTTPS-Website zu befinden und auf einen HTTP-Link zu klicken, wird vorher noch die unsichere HTTP-Website von Google aufgerufen und von da aus weitergeleitet, mit allen Referer-Informationen, zu www.test.de.
Der Live HTTP Headers Mitschnitt sieht dabei wie folgt aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDgQFjAA&url=http%3A%2F%2Fwww.test.de%2F&ei=DWvwTtS0CYuLswaNhZXZDw&usg=AFQjCNExSl_aJh-irODpoIla40aIiDVM-w&sig2=m74yiQYMt6l1N7JllreP6A GET /url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDgQFjAA&url=http%3A%2F%2Fwww.test.de%2F&ei=DWvwTtS0CYuLswaNhZXZDw&usg=AFQjCNExSl_aJh-irODpoIla40aIiDVM-w&sig2=m74yiQYMt6l1N7JllreP6A HTTP/1.1 Host: www.google.de User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Cookie: NID=54=W_Q_rZ0Cs_S9ha7spxFvpVd_IhbYXVRvcEYsMbQ5CeYRewuEe4SNexvrj9xuNoMOgIJIMicL85ORRqRumL8HYsEjiiVWRGBu5sryUaJGvAtKKsYqvvzzXrgQxYqscF3a; PREF=ID=fab90f5ee8802a54:U=1d45479558ea1106:FF=0:LD=de:TM=1302009746:LM=1324378894:SG=2:S=y4XEaQbQVQPAGqTM; SID=DQAAAO0AAACMl4hFmyosut3Tki8tBYzFGmkmkbLucIyr2IOfS-R0r07FPG1j3DVWecIe0c6JtAe04UNZuo0nBBkAwQNrK7JU2NjbZJxjbhiMAk6mzWDNqns3p7UWrLNDwY3VSRihVW2VIVHkiTUCWQlRSQ6W0P8EuzhiVkFs68kNg0af_tDLZGCy2anRpMu3-cukadDMW7_3dFa9JVCJlLRJ25L6Y60PogKaf38EP1mOSCBRuNbz3S7Oq67loMYTzt315_JWmrTQRH1L8sCRwvmL2wAGx-vjqD9OfNn3cQDOKixROAb-gwiB0hBcx54HNdTPoBieGc4; HSID=AtSC5G5LPWM8K_1mR; SSID=AkGNJTyOmqXQc2D63 HTTP/1.1 200 OK Date: Tue, 20 Dec 2011 11:06:26 GMT Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Cache-Control: no-cache, must-revalidate X-Frame-Options: ALLOWALL Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip Server: gws Content-Length: 226 X-XSS-Protection: 1; mode=block ---------------------------------------------------------- http://www.test.de/ GET / HTTP/1.1 Host: www.test.de User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Referer: http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDgQFjAA&url=http%3A%2F%2Fwww.test.de%2F&ei=DWvwTtS0CYuLswaNhZXZDw&usg=AFQjCNExSl_aJh-irODpoIla40aIiDVM-w&sig2=m74yiQYMt6l1N7JllreP6A HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Expires: -1 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 Set-Cookie: ASP.NET_SessionId=yj3frz0kjpoorxhqk5zqf25v; path=/; HttpOnly X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 20 Dec 2011 11:07:19 GMT Transfer-Encoding: chunked |
Führt man dieses Experiment mit einer deaktivierten Einstellung für JavaScript im Browser aus, so wird bei Google korrekt die Ziel-URL aufgerufen, ohne das Mitsenden von Referer-Informationen. Etwas dreister ist hier Facebook, deaktiviert man JS so werden URLs nicht mehr maskiert und über JS weitergeleitet sondern zeigen eine gezielte Umleitung auch schon im Browser. Referer Informationen werden auch dann mitgeschickt, über Umwege und Umleitungen über verschiedene URLs.
Etwas kurios, dass die ganz Großen hier mit Umleitungen nicht geizen um Informationen über Klickverhalten zu sammeln. Jedoch sich nach Außen als Vorreiter des sicheren Surfens titulieren. Greenwash gibt es für große Brands in der Industrie, wobei Marken durch Marketing mit Umweltbewustsein in Verbindung gebracht werden sollen. Dann ist „Savewash“ das Pendant dazu für Internet Marken, die gerne mehr Datenschutz nach außen tragen würden, hinter dem Rücken der Nutzer es jedoch nicht sind. Denn die wenigsten Internetnutzer werden das RFC 2616 gelesen haben.
Wie denkt Ihr zu diesem Thema? Bin ich hier über etwas gestoßen, was schon lange bekannt ist? Oder ist es ein unwesentliches Detail, was hier betrieben wird? Ein Faux-pas, bei dem man ein Auge zudrücken sollte? Steckt doch mehr dahinter?
Ich freue mich über Eure Kommentare!
Sehr guter Artikel – und schöne Seite. Vielleicht schau ich jetzt öfter vorbei. Ist ja echt witzig, dass Du in ähnlichen Fachbereichen unterwegs bist wie ich. Das mit dem Javascript durchblickt kein normaler Mensch – ausser wir Sinners ;-). Das nutzen die Datenkraken schamlos aus. Man sollte mal klagen gegen leere Behauptungen. Wenn Du eine Unterschriftenaktion starten willst, kann ich leider nicht mitmachen, da ich gleich heiße wie Du.
Hi
cooler Artikel. Wusste garnicht was da alles so passiert…
Wenn ich das richtig verstehe ist das löschen des Referrers also normal bzw so gewünscht. Aber die Seiten leiten noch unnötig rum um an mehr informationen zu kommen?!? Welche Informationen sind gemeint? Im Grunde kann es doch nur um den klick-out gehen, also WELCHER Link geklickt wurde, oder?
Gruß
Jan
Danke für die Kommentare!
@Jan, bei HTTPS wird keine Referrer Information übertragen (oder soll). Dh die angeklickte Seite weiß eigentlich nicht, woher du gekommen bist. Was auf der Webseite (Google) selbst passiert hat damit erstmal nichts zu tun. Es geht darum, dass Google aus „Sicherheitsgründen“ das Keyword durch „NotProvided“ ersetzt, obwohl es garnichts übertragen dürfte.
@Michael: irgendwie fühl ich mich gleich so dupliziert 😉