Markus Baersch

Zugegeben: Referrer Spam ist ein Google Analytics Problem. Dort finden sich in vielen ungefilterten Datenansichten solche künstlich generierten Einträge in der Liste der verweisenden Websites.

Ebenso hinterlassen Spammer automatisiert erzeugte Spuren in anderen Reports zur Webanalyse: Event-Spam, Page-Spam... und sogar im Language Report werden Daten erzeugt, die im weitesten Sinne der "Bewerbung" zweifelhafter Angebote im Web dienen sollen. Wenngleich es zahlreiche Möglichkeiten zur Behandlung dieses Leids gibt, bleibt Analytics-Spam ein Ärgernis.

Das Measurement Protocol als Auslöser?

Wenn ich mit Webmastern oder Online-Marketern über das Google Analytics Measurement Protocol (GAMP) – und den naheliegenden Zusammenhang mit o. g. Spam – rede, begegne ich häufig der Meinung, dass Webanalyse-Spam ausschließlich deshalb existiert / möglich ist, weil es das Measurement Protocol gibt. Das ist m. E. ebenso zu kurz gedacht wie die daraus abgeleitete Meinung, dass ausschließlich Google Analytics betroffen sei.

Richtig ist: Das GAMP erleichtert Spam allein dadurch, dass hierbei alle Attribute, Signale und Informationen, die üblicherweise "implizit übertragen" werden, wenn ein Trackingaufruf erfolgt (z. B. Browser, Betriebssystem etc.), auf explizite Weise als Parameter mit beliebigen Werten belegt werden können. Denn das ist der Zweck des GAMP. Möglichst alle Informationen, die in Analytics ausgewertet werden können, sollen darüber losgelöst vom üblichen Tracking in Websites und Apps transportierbar werden.

Spammer brauchen Reichweite

Auch ist unbestreitbar, dass Google Analytics allein durch den hohen Marktanteil das meiste Potential für Webanalyse-Spammer bietet. Da ist Google Analytics nicht allein. Windows galt so lange als besonders angreifbar und "Virenplattform", bis auch der Mac – oder später das iPhone und Android-Smartphones – genug Marktanteil erreicht hatten, so dass es in Sinne einer hohen Verbreitung auch auf diesen Plattformen "sinnvoll" erschien, Viren und Schadprogramme bereitzustellen. Ebenso existieren nur deshalb so viele bekannte Hacks und Angriffsvektoren für WordPress, weil es so weit verbreitet ist. Das bedeutet nicht, dass andere Systeme per se sicherer wären... nur eben "uninteressanter" für die Masse der Spammer.

Ebenso verhält es sich mit Webanalyse-Spam. Google Analytics bietet zwar zusätzlich zur hohen Verbreitung und dem Measurement Protocol noch den großen "Vorteil"; dass Spammer einfach beliebige Property-IDs "raten" und eine Zeitlang mit Daten beschießen können, ohne dass man solche Angriffe auf einzelne Websites richten muss, aber spätestens dann, wenn eine bestimmte Website im Visier steht, können mit vertretbarem Aufwand auch andere Systeme angegriffen werden.

Das Spam-Experiment

Eine besuchte Webseite mit einem Trackingcode eines beliebigen Anbieters muss die benötigten Informationen zum jeweiligen Trackingserver übertragen. Dazu werden i. d. R. durch den Trackingcode bestimmte URLs auf den Servern des Systemanbieters aufgerufen, deren Parameter einige der Angaben wie z. B. den Seitentitel, Informationen über die Herkunft des Besuchers und auch dessen Identifikation beinhalten. Hier sollte es also auch bei anderen Anbietern unter Verwendung der passenden Werte für die Identifizierung der jeweiligen Domain und des zugehörigen Tracking-Profils beim Trackinganbieter möglich sein, über automatisierte Aufrufe künstliche Daten in der Webanalyse zu erzeugen, die nichts mit realen Besuchern der Website zu tun haben und für die auch kein Browser erforderlich ist.

Aus dieser Perspektive habe ich mir eTracker und Piwik als verbreitete alternative Lösungen ausgewählt, dort Testaccounts zum Befeuern angelegt und dann den abgesetzten Hits der jeweiligen Trackingcodes über die Schulter geschaut.

Grundsätzlich braucht man für Referrer Spam nicht viel. Es müssen nur "irgendwie" künstliche Ereignisse wie z. B. Seitenaufrufe erzeugt werden, die als Herkunft eine bestimmte verweisende Website ausweisen müssen. Hat man dabei keinen besonderen Ehrgeiz, diese falschen Hits mit entweder möglichst vielen Informationen anzureichern oder auf der anderen Seite möglichst viele für das gesetzte Ziel unnötige Informationen zu übertragen, reichen i. d. R. ein paar wenige Versuche aus, die man für den Start sogar selbst direkt im Browser aufrufen kann. Gleicht man die Parameter zusätzlich mit den Informationen ab, die im jeweiligen Cookie gespeichert werden, den man sich beim ersten Testaufruf einer mit dem realen Code getaggten Seite einfängt, kann man auch eine beliebige Anzahl von verschiedenen Benutzern simulieren, wenn man nicht nur Seitenaufrufe, sondern auch möglichst viele Besucher / Sessions erzeugen möchte. Denn Spam ist ja nur dann wirkungsvoll, wenn er in Reports in den jeweiligen Top-Listen auftaucht.

Automatisierter Referrer-Spam

Für den reinen Nachweis der Machbarkeit würde jeweils ein einziger Hit ausreichen, den man ohne den üblichen Weg über die vermessene Website in die Webanalyse gebracht hat. Das macht aber zu wenig Spaß 😉 Daher habe ich mein ursprünglich (freilich nur zu Demonstrationszwecken!) auf Google Analytics ausgerichtetes Spamscript (liebevoll den "Astleynator" genannt) so angepasst, dass auch passende Hits für eTracker und Piwik abgesetzt werden können.

Damit habe ich den jeweiligen Seitenbericht so lange mit Fakedaten bespielt, bis er den Text von Rick Astleys Jahrhundertwerk wiedergibt, wenn man die Seiten (bzw. im Fall von eTracker die Titel) absteigend nach Seitenaufrufen sortiert. Jeder der Hits hat der Einfachheit halber einen erfundenen Spam-Domainnamen als Referrer mitgebracht, um eben vor allem dort ähnliche Spuren zu hinterlassen, wie sie auch von Spammern in Google Analytics generiert werden.

Fake-Verweise im eTracker...

Das Ergebnis zeigt, dass auch mit eTracker vermessene Websites zum Ziel solcher Angriffe werden können. Allerdings nicht so "leicht" wie bei Google Analytics, denn man muss sich hier vorher tatsächlich vom realen Trackingcode abgesetzte Hits ansehen und sich dort neben der ID (die auch im Trackingcode selbst steht) noch einen Hashwert (Parameter dh) abholen, um dann eigene Hits erfolgreich in die Reports zu bekommen.

Die hier ausgewiesenen Seitenaufrufe erzeugen korrekt sortiert den o. a. "Rick Astley Report":

... und in Piwik

Nach gleichem Muster kann man auch Piwik mit falschen Daten versorgen. Dazu muss man hier offenbar nur wissen, an welchen Server (eigener Trackingserver oder Subdomain bei der Hosted-Variante) die Hits gesendet werden müssen; der Rest besteht aus wenigen Parametern wie URL, Titel der Seite und dem Referrer, den man vorspiegeln will. Schon kann man hier das gleiche Ergebnis erzeugen.

Auch hierzu der passende "Rick Astley Report":

Fazit

Zwei andere Systeme sind noch lange nicht "alle anderen". Es ist durchaus denkbar und mit recht simplen Mitteln lösbar, solche Spam-Attacken abzuwehren; es besteht nur kaum eine Veranlassung dazu, weil es dort kein vergleichbares massenhaftes Spam-Problem gibt. Auch kann man nicht überall (wie bei Google) alle beliebigen Attribute selbst mit Daten belegen. So wäre es im Fall des eTrackers z. B. auch etwas komplexer, dort Event-Spam zu hinterlassen oder jenseits von Kampagnenparametern, dem Referrer und der Seite andere Merkmale zu belegen. Jedenfalls nicht mit dokumentierten Parametern wie im Fall des Measurement Protocols.

Nur weil andere Systeme aber nicht im Fokus von Spammern stehen, sind diese nicht automatisch sicherer. Zumindest das sollte mit diesem Experiment ausreichend nachgewiesen sein. Und wer schon immer Lust hatte, etwas anderes als eine Website zu messen und dabei nicht auf Google Analytics zurückzugreifen, mag sein nächstes Logging – Projekt ja vielleicht mit Piwik statt Analytics umsetzen. Falls ja: Lass es mich wissen 😉