HTTP auswertenSpurensuche
Sniffer
HTTP auswerten
Das HTTP-Protokoll ist aus technischer Sicht faszinierend: Auf 176 Seiten wird die Basis für das Web gelegt (www.ietf.org/rfc/rfc2616.txt). Sicherlich, die offizielle Spezifikation für HTTP 1.1 bei der IETF (Internet Engineering Task Force) wird noch von anderen Spezifikationen ergänzt, aber die Kernidee und die wichtigsten Anweisungen passen, wenn auch nicht auf einen Bierdeckel, so doch zumindest auf weniger Blätter als eine Steuererklärung.
Nun ist die Frage, wie Sie dieses Protokoll und die Informationen, die es liefert, nutzen können. Zunächst sollten Sie einen Blick auf den HTTP-Header werfen. Eine erste Anlaufstelle sind webbasierte Sniffer wie
www.delorie.com/web/headers.html. Dort können Sie zumindest die Server-Antwort näher analysieren. Web-sniffer.net bietet auch die Möglichkeit, Browser-relevante Einstellungen wie den User-Agent-String, der den Browser identifiziert, einzugeben.
Noch etwas praktischer sind HTTP-Schnüffler für den Browser selbst. Häufig eingesetzt wird beispielsweise Live HTTP Headers für den Mozilla Firefox (
livehttpheaders.mozdev.org). Dieses Projekt ist Teil der Mozilla Community und bietet ein Plug-in für den Browser. Aktuell ist die Version 0.1. Nach der Installation findet sich das Plug-in im Menü Extras, Live HTTP headers. Im Register Header muss das Kontrollkästchen Mitschneiden aktiviert sein, um die Header zu speichern. Im Register Generator legen Sie im Detail fest, was mitgeschnitten wird. Vor allem die Header von Grafiken und CSS sollten Sie deaktivieren, um sich in den verschiedenen HTTP-Headern noch zurechtfinden zu können. Für andere Browser wie den Internet Explorer gibt es natürlich ähnliche Tools, zum Beispiel www.blunck.info/iehttpheaders.html.
Infos on Tour
HTTP auswerten
Die Einsichten in das HTTP-Protokoll und den Datenverkehr im Netz können immer aus zwei Perspektiven genutzt werden: aus der des Nutzers oder der des Webservers beziehungsweise des Site-Betreibers. Aus der Perspektive des Nutzers interessiert hauptsächlich, welche Informationen der Server durch die Gegend schickt. An erster Stelle stehen natürlich Cookies, die im HTTP-Header übermittelt werden.
Aber auch der Webserver unter Server oder die serverseitige Technologie bei X-Powered-By sind interessante Informationen. Allerdings lassen sich die Angaben des Servers natürlich ähnlich wie die des Clients beliebig fälschen ? beispielsweise sind Serverangaben ohne Versionsnummern üblich, um nicht Angriffen für bestimmte Sicherheitslücken ausgeliefert zu sein. Auch Versionsnummern von PHP oder anderen serverseitigen Technologien können eher peinlich enden, wenn der Hoster eine längst veraltete Version verwendet. Im Web gilt eben leider nicht »Never touch a running system«.
Zusammengefasst erhalten Nutzer unter Umständen durchaus sicherheitskritische Angaben über HTTP. Dazu kommt, dass sich ein Nutzer natürlich immer eine beliebige Anfrage an ein serverseitiges Skript selbst zusammenbasteln und so Sicherheitslücken ausnutzen kann.
In diesem Artikel interessiert aber die Gegenrichtung: Was kann der Anwender über den Client herausfinden und wie kann er es sinnvoll einsetzen?
Logging, Teil 1
HTTP auswerten
Klassische Logfiles, die der Server mitschneidet, bieten eine Vielzahl an Informationen: wie viele Visits, welche Browser und vieles mehr. Diese Informationen werden größtenteils aus der HTTP-Anfrage des Browsers gezogen. Nun ist aber das Logfile kein wirklich dynamischer Weg, auf solche Informationen zu reagieren. Deswegen bieten die meisten serverseitigen Technologien Schnittstellen, um auf die Teile der HTTP-Anfrage zu reagieren.
In diesem Artikel dient PHP als weit verbreitete Technik als Beispiel. In PHP finden Sie nicht nur Server-Informationen, sondern auch HTTP-Daten im superglobalen Array $_SERVER. Ein schneller Test zeigt, was im Einzelnen verfügbar ist:
print_r($_SERVER);
Neben den üblichen Logging-Basics wie dem Browser ($_SERVER[?HTTP_USER_AGENT?]) erhalten Sie über $_SERVER[?HTTP_ACCEPT_LANGUAGE?] die Information über bevorzugte Sprachen. Aus beiden lässt sich für mehrsprachige Websites auf die jeweilige Nutzersprache reagieren.
Hilfsbibliotheken
HTTP auswerten
Wem $_SERVER nicht ausreicht oder nicht komfortabel genug ist, der sollte einen Blick auf die Pear-Bibliotheken für HTTP werfen (pear.php.net/packages.php?catpid=11&catname=HTTP). Eine praktische Bibliothek ist HTTP_Request, mit der Sie einen beliebigen HTTP-Request an Ihren Server senden können. Dies ist auch nützlich, um zum Beispiel Test-Requests für die später gezeigten Referrer-Beispiele zu konstruieren.
Hier ein einfaches Beispielskript, das auf die Internet-Professionell-Website geht und den HTTP-Response-Header ausliest:
<?php
require_once 'HTTP/Request.php';
$req = new HTTP_Request('http://www.itespresso.de/ipro/');
if (!PEAR::isError($req->
sendRequest())) {
echo 'HTTP-Response:
';
$resp = $req->getResponseHeader();
foreach ($resp as $name => $wert) {
echo $name . ': '
. htmlspecialchars($wert) . '
';
}
}
?>
Referrer
HTTP auswerten
Besonders interessant in Sachen Personalisierung ist der HTTP-Referrer. Dieser HTTP-Befehl enthält den URL, von dem ein Nutzer auf eine Seite kommt. Pflicht dafür ist natürlich das Anklicken eines Links. Hat der Nutzer die Adresse in der Adressleiste des Browsers eingegeben, gibt es keinen Referrer.
Um den Referrer auszulesen, reicht Javascript völlig aus:
<!?
document.write("Referrer: " + document.referrer);
//?>
Vorsicht sollten Sie allerdings walten lassen, wenn Ihre Website mit einer Weiterleitung versehen ist, wie das beispielsweise bei einigen CMS der Fall ist. Dann muss natürlich auf der weiterleitenden Seite der Referrer abgefragt werden.
Referrer verarbeiten
HTTP auswerten
Nun ist die Frage, was mit dem Referrer alles anzufangen ist. Der wichtigste Praxisansatz ist die Reaktion auf Suchbegriffe. Sehen Sie sich dazu einfach mal einen üblichen Google-URL für eine Suche an:
http://www.google.com/search?q=Hauser+Wenz&l=de
Er besitzt als Werte für den URL-Parameter q die Suchbegriffe, hier Hauser und Wenz. Solche GET-Parameter werden beim HTTP-Referrer ebenfalls mitgeliefert.
Das heißt also, Sie müssen nur die Suchwörter herausfiltern, um speziell darauf reagieren zu können. Hier ein Beispiel in PHP:
<?php
if (isset($_SERVER['HTTP_REFERER'])) {
$ref = $_SERVER['HTTP_REFERER'];
$start = strpos($ref, 'q=') + 2;
$ende = strpos($ref, '&', $start);
$laenge = $ende - $start;
$suche = substr($ref, $start, $laenge);
$begriffe = explode('+', $suche);
foreach ($begriffe as $begriff) {
echo htmlspecialchars(
urldecode($begriff))
. '
';
}
}
?>
Der Referrer wird in $_SERVER[?HTTP_REFERER?] gespeichert. Der Rest besteht aus ein wenig String-Manipulation. Zuerst wird der Parameter identifiziert und dann bis zum Ende abgeschnitten. Mit der Funktion explode() werden die einzelnen Suchbegriffe immer beim Pluszeichen getrennt und in ein Array gespeichert.
Zum Testen verwenden Sie einfach eine HTML-Seite, die das Skript verlinkt, und übergeben im Browser die entsprechenden URL-Parameter. Im Beispiel wird das Array ausgegeben, aber hier sind andere Anwendungen ebenso denkbar: Eine Methode wäre das Logging der Suchbegriffe. Noch eleganter ist es, wenn Sie direkt auf die Suchbegriffe reagieren.
Suchmaschinenoptimierung
HTTP auswerten
Je differenzierter das geschieht, desto effektiver: Sie können zum Beispiel ein bestimmtes Produkt einblenden, das zum Suchbegriff passt. Oder aber Sie lassen den Begriff durch Ihre Site-Suche laufen und geben an gut sichtbarer Stelle die Ergebnisse aus.
Natürlich haben Sie auch die Möglichkeit, nur im Verborgenen mitzuloggen und Ihre Suchmaschinenoptimierung entsprechend der neuen Erkenntnisse anzupassen. Das Einzige, worauf Sie achten sollten, ist, dass der URL-Parameter im HTTP-Referrer von böswilligen Nutzern mit SQL-Injections oder XSS (Cross-Site Scripting) und Ähnlichem versehen werden könnte: Hier sollten Sie also filtern.
Andere Suchmaschinen verwenden übrigens eine ähnliche Syntax wie Google. Meist unterscheidet sich nur der Buchstabe für den URL-Parameter. Altavista setzt ebenfalls auf ein q:
http://de.altavista.com/web/results?itag=ody&q=Hauser+Wenz&kgs=1&kls=0
Yahoo verwendet p:
http://de.search.yahoo.com/search?fr=fp-tab-web-t-1&ei=ISO-8859-1&p=Hauser+Wenz&meta=vl%3D
und Web.de setzt auf die zwei Buchstaben-Kombination su:
http://suche.web.de/search/?mc=hp%40suche.suche%40home&su=Hauser+Wenz&webRb=de
Je nachdem, welche Suchmaschinen Sie unterstützen möchten, müssen Sie einfach nur die oben gezeigte Abfrage ein wenig anpassen.
Logging, Teil 2
HTTP auswerten
Der HTTP-Referrer war ursprünglich auch dazu gedacht, auf einer Seite Listen mit den Seiten zu zeigen, von denen aus verwiesen wird. Weblog-Software hat sich dies besonders zunutze gemacht. Allerdings haben findige Schurken die schlimme Lücke im System ausgenutzt: Die HTTP-Anfrage lässt sich manuell auf triviale Art zusammenstellen, und teilweise ist der Referrer auch im Browser abschaltbar.
Richtig gefährlich wird das Ganze aber, wenn das Skript eines böswilligen Nutzers automatisiert die HTTP-Anfrage zusammenstellt. Dann verweisen spezialisierte Robots auf eine Blog-Seite, die mit den häufigsten Referrern hausieren geht. Schnell sind dann irgendwelche dubiosen Porno- und Glückspielseiten an der Spitze der Rangliste. Deswegen hat der offene Einblick in die eigenen Referrer heute eher ausgedient und wurde in der Blog-Software durch andere Systeme wie Trackback (www.sixapart.com/pronet/docs/trackback_spec) und Pingback (www.hixie.ch/specs/pingback/pingback) ersetzt. Bei diesen Methoden kommunizieren die Websites über eine XML-RPC-Schnittstelle, um Neuerungen beziehungsweise Querverlinkungen zu melden.
Für die Statistik sind Referrer noch aus einem anderen Grund schwierig: Leicht unterschiedliche Schreibweisen von URLs werden als verschiedene Ursprünge wahrgenommen.
http://www.xy.de/test
ist also etwas anderes als
http://www.xy.de/test/
obwohl der Webserver sowohl die eigentlich nicht ganz korrekte erste Variante genauso akzeptiert wie die zweite. Hier hilft nur umfangreiches Filtern.
Andere Richtung
HTTP auswerten
Ist der Nutzer beim Betreten der Seite schon mitgeloggt worden, ist es natürlich auch sinnvoll, ihn beim Verlassen zu beobachten und so Nutzerpfade zu erhalten. Dazu gibt es einen einfachen Trick, den auch viele Suchmaschinen wie Google und viele Content-Management-Systeme verwenden: Beim Klick auf einen Link wird der Nutzer auf eine Zwischenseite umgeleitet, die den Klick mitloggt.
function weiterleitung(ele) {
ele.href="log.php?url=" + escape(ele.href);
return true;
}
Hat der Besucher Javascript deaktiviert, passiert nichts Schlimmes, da dann die Weiterleitung scheitert und der normale Link ausgeführt wird. Das heißt also, die statistische Verzerrung besteht darin, dass Nutzer ohne Javascript nicht mitgeloggt werden. In der Praxis ist dies meist zu vertreten.
Das Skript für das Logging kann natürlich umfangreich sein, muss es aber nicht. Im Prinzip reicht es, den angeklickten URL in eine Datei zu schreiben und dann auf die angegebene Adresse weiterzuleiten. Hier der passende PHP-Code:
<?php
if (isset($_GET['url'])) {
file_put_contents('log.txt',
file_get_contents('log.txt')
. urldecode(nl2br($_GET['url'])) . ', ');
header('Location: ' . urldecode($_GET['url']));
} else {
echo 'Kein URL angegeben.';
}
?>
Fazit
HTTP auswerten
Die Zusatzinformationen, die Ihnen HTTP und die hier gezeigten kleinen Skripts liefern können, sind nur der Einstieg in eine intelligente Logging- und Personalisierungs-Strategie. In der Praxis müssen solche Ansätze meist in komplexere Anwendungen wie Content-Management-Systeme, Shops oder Intranets integriert werden. Der damit verbundene Aufwand lohnt sich allerdings, wenn Sie dadurch Ihren Nutzer besser kennen lernen.
Alle Dateien und Listings aus dem Workshop finden Sie auf der Heft-CD und unter listings.internet-pro.de.