Vertrau’ mir …

Heise berichtet über Open redirects. „Open Redirects“ funktionieren derart, dass eine Seite aufgerfen wird, die eine andere Seite aufruft. Webmaster benutzen dies, um das Klickverhalten zu ermitteln.

Letztendlich ist das so: Um die Klicks auf die Links zu zählen, die man auf der Seite hat, baut man sich ein PHP-Script. Das macht nichts weiter, als einen Counter um eins zu erhöhen, und dann an die übergebene Seite weiterzuleiten.

http://example.net/click.php?url=http://example.com

… ruft zuerst mal das Script „click.php“ auf. In diesem Script wird der eben angesprochene Counter erhöht, und das Ganze zur Auswertung in eine Datenbank oder so eingetragen. Zusätzlich wird dem Script ja der Parameter „url“ übergeben. Es wird also nicht einfach auf die Seite weitergeleitet, sondern vorher noch anderes Zeug gemacht (eben der Counter erhöht).

Nach dem Erfassen des Klicks durch das Script in „click.php“, wird am Ende eben dieses Scripts auf die entsprechende Seite, die durch „url“ an das Script übergeben wurde, weitergeleitet – Wie gesagt, eine durchaus legitime Funktionsweise, mit der Webmaster gucken können, welche ihrer Links angeklickt wurden, ohne auf Clientseitige Sachen, wie JavaScript zurückgreifen zu müssen.

Wenn man so einen Link zur „click.php“ nun nicht anklickt, sondern durch kopieren oder abtippen aus der Seite herausholt, kann man dort natürlich selbst irgendwas dranhängen, und zwar unabhängig davon, ob der Webmaster auf seiner Seite so einen Link gesetzt hat.

http://example.net/click.php?url=http://blog.schlunzen.org

Hier passiert wieder genau das Selbe, wie bei dem Original-Link: Der Klick (oder eben der direkte, händische Aufruf dieses URL) startet das Script „click.php“, der Counter wird erhöht, das Ergebnis wird in die Datenbank geschrieben und dann die übergebene Seite aufgerufen.

Anstatt auf eine Harmlose Seite zu verweisen, kann man diese Methode natürlich auch dazu benutzen, an Passwörter zu kommen. Stellen wir uns mal vor, auf example.com gibt es ein Login-Interface. Zusätzlich erfasst der Webmaster der Seite die Klicks durch das „click.php“-Script. Ein Angreifer baut das Login-Interface nun nach.

http://example.com/click.php?url=%68%74%74%70%3A%2F%2F%6d%61%6c%6c%6f%72%79%2E%69%6e%76%61%6c%69%64

Ein unbedarfter Anwender bekommt nun eine Mail zugeschickt, mit der Bitte sich zu Wartungszwecken einmal einzuloggen. Er guckt sich den Link an, sieht seine example.com-Seite, und hinten dran „irgendwelchen Zeichensalat, der zum Erkennen oder so genutzt wird“, da vorne aber seine bekannte Seite steht, denkt er sich nichts dabei, klickt drauf, sieht sein Login-Feld, und meldet sich an.

in wirklichkeit ist er aber auf „http://mallory.invalid“ gelandet. Der „Zeichensalat“ ist nämlich nichts weiter als ein komplett URL-Kodierter URL. Zum Beispiel hat dommermuth-1.com einen Decoder. Dort die Daten reingehauen und auf „Test“ geklickt, und schon bekommt man

http://example.com/click.php?url=http://mallory.invalid

raus. Und was das macht, habe ich ja weiter oben schon angesprochen (Counter, Eintragen, Weiterleiten). Wenn die Seite nun perfekt nachgebaut ist, und der Anwender nicht noch mal zusätzlich in die Adresszeile guckt, wird er glauben, seine normale Login-Seite zu sehen.

Der böse Webmaster kann nun natürlich ein Script benutzen, das beim Abschicken des gefälschten Formulars die Login-Daten speichert, und dann auf die echte example.com-Loginseite weiterleitet. Entweder übergibt er dabei gleich per PHP die Anweisungen zum Login (das ist recht einfach möglich), oder hofft darauf, dass der User glaubt, er habe sein Passwort falsch eingegeben.

Als User kann man nur bedingt einfluss darauf nehmen. Und zwar kann (und sollte) man immer darauf achten, ob und wie der Login-vorgang sich verändert hat, und bei Änderungen genauer nachprüfen, was los ist. Firefox 3 macht es einem da mittlerweile recht einfach, da deutlich und unmissverständlich angezeigt wird, ob und mit welcher signatur die Verbindung verschlüsselt ist.

Es ist auch Ratsam, sich nur über einen Bookmark bei seinen Seiten einzuloggen, und die Links in mails nicht zu verwenden, auch, wenn es bequemer zu sein scheint.

Als Webmaster hat man realistisch betrachtet zwei Möglichkeiten: Alle Links, die über „click.php“ aufgerufen werden sollen, müssen in einer Datenbank stehen, wird nun ein Link aufgerufen, der nicht in der DB steht, gibt es eine Fehlermeldung, alternativ kann man mit IDs arbeiten.

http://example.com/click.php?id=4232

In der Datenbank ist dann 4232 mit einem bestimmten URL verknüft. Das Script ruft nun also nicht mehr ds auf, was per Parameter übergeben wurde, sondern fragt die Datenbank ab, und ruft dann den zurückgegebenen Link auf, oder eben eine Fehlermeldung.

Diese Technik benutze ich auf einer meiner Seiten in Verbindung mit einer .htaccess-Umleitung. Der Aufruf wird intern dann an das Testscript weitergeleteitet, das dann natürlich den Parameter bekommt, und die ID in der Datenbank abfragt, und auf die Hinterlegte Seite weiterleitet.

http://meine-seite.invalid/4232

Man kann man als Webmaster auch einfach darauf verzichten, das Klickverhalten mit dieser Methode zu erfassen. Alternativ kann man diese Funktion auch mit JavaScript und XML-RPC-Calls bauen, setzt natürlich voraus, dss im Client JavaScript aktiviert ist.

Aber egal, was man tut, Usereingaben sollten immer bereinigt werden, oder zumindest aber überprüft.

Einen Kommentar hinterlassen