Web-Trojaner: Webanwendungen sicher programmieren

• Home
• Magazin
• Know How
• Virus, Malware & Spamschutz

Im Mai 2000, als das Web so etwa zehn Jahre alt war, richtete Jim Fulton (er gehörte zu den Entwicklern des Zope Application Server) sein Augenmerk auf eine sehr einfache, aber sehr erschreckende Sicherheitsproblematik. Die Zope-Leute nannten das Problem "clientseitige Trojaner" – ein etwas verwirrender Begriff. Das Wort "Trojaner" stammt aus der griechischen Legende über das trojanische Pferd. Heute wird der Begriff "trojanisches Pferd" verwendet, um etwas zu beschreiben, das wie ein Geschenk aussieht, in Wirklichkeit aber eine Falle ist. In Zusammenhang mit Computersicherheit bezeichnet der Begriff "ein Programm, das cool aussieht, aber alle Dateien löscht".

Die von Jim Fulton beschriebene Problematik hat wenig zu tun mit dem Löschen von Dateien und anderem erschreckendem Zeug, das auf der Clientseite passieren kann. Eigentlich hat sie überhaupt nichts mit dem zu tun, was sich die meisten Leute unter "Programmen", d. h. ausführbaren Dateien, vorstellen. Das Problem, um das es geht, besteht darin, dass es einem Angreifer gelingen könnte, andere Benutzer durch eine E-Mail oder einen Link dazu zu bringen, sich auf eine Website zu klicken, die sie nie im Sinn hatten. Das geht wieder auf die allgemeine Bedeutung des Begriffs "Trojaner" zurück: eine Falle, die sich hinter etwas Harmlosem verbirgt.

Beispiele

Das Problem lässt sich am leichtesten anhand von Beispielen beschreiben. Bevor wir uns mit Onlinebanken (ja, dort kann es auch funktionieren) befassen, beginnen wir mit etwas Einfacherem. Um Statistiken zu erfassen, können Benutzer auf einer Abstimmungssite zwischen verschiedenen Alternativen wählen. Die Abstimmungsseite könnte folgenden HTML-Text enthalten:

<form action="http://www.voting.example/vote.asp" method="get">
<input type="radio" name="alt" value="1"/>Foo<br/>
<input type="radio" name="alt" value="2"/>Bar<br/>
.
.
.
</form>

Da im Formular die GET-Methode benutzt wird, besuchen Benutzer beim Abstimmen URLs wie diese, wenn sie das Formular abschicken:

http://www.voting.example/vote.asp?alt=2

Was hält einen Angreifer davon ab, die obige URL zu kopieren und mit dem Vorwand an viele Leute zu schicken, sie führe zu einem coolen Spiel, Nackedeis, Katastrophenmeldungen, Witzen oder was immer nötig ist, um Leute zum Besuch des Links zu überlisten? Nichts. Folgen mehrere der angesprochenen Personen dem Link, geben sie alle eine Wählerstimme nach dem Dafürhalten des Angreifers ab, und die Statistiken sind letztlich falsch.

Sie haben gegen dieses Beispiel vielleicht mehrere Einwände. Erstens könnten Sie sagen, dass viele Benutzer einem Link wie diesem nicht folgen würden, weil er verdächtig aussieht. Das ist kein Problem. Der Angreifer kann die URL mittels Umleitung vor kundigeren Benutzern verbergen. Statt direkt auf die Abstimmungssite zu zeigen, führt sie zu einer Seite auf seinem eigenen Server, z. B.:

http://www.badguy.example/nicejoke.html

Selbstverständlich befinden sich im Gegensatz zu den Erwartungen des Benutzers auf der Seite nicejoke.html keine Spiele. Stattdessen enthält sie folgenden HTML-Text:

<meta http-equiv="refresh"  content="0,url=http://www.voting.example/vote.asp?alt=2"/>

Nachdem der Browser das meta-Tag gelesen hat, führt er eine Umlenkung auf die URL zur Abstimmungssite durch, noch ehe der Benutzer merkt, was vor sich geht. Das Gleiche kann mit Hilfe eines Skripts oder Location-Headers erreicht werden.

Wie manch einer weiß, ist die Verwendung einer GET-Anfrage in dieser Situation falsch. Und das ist wahrscheinlich Ihr zweiter Einwand. Der RFC 2616 definiert HTTP und legt fest, dass man POST-Anfragen verwenden sollte, wenn die Aktion Seiteneffekte hat. Mit POST ist es unmöglich, die Abstimmungsdetails in einer URL zu kodieren, weil Parameter in POST-Anfragen in der Anfrage selbst verborgen werden. (Einige Web-Anwendungen achten aber nicht auf den Unterschied zwischen POST und GET, so dass sie GET-Anfragen dort akzeptieren, wo sie ursprünglich POST wollten.) Das hält den Angreifer aber nicht davon ab, sein Ziel zu erreichen. Er verleitet den Browser zum Ansehen eines automatisch abgeschickten Formulars statt zum Besuch der obigen URL:

<form name="f" action="http://www.voting.example/vote.asp" method="post">  
<input type="hidden" name="alt" value="2"/>  
</form>  
<script>document.f.submit()</script>

Das mit f bezeichnete Formular enthält ein verborgenes Feld, in dem der alt-Parameter bereits auf die Wahl des Angreifers gesetzt ist. Unter dem Formular versteckt sich ein kleines JavaScript-Programm. Das Skript schickt das Formular genauso, als hätte der Benutzer auf einen fiktiven "Abschicken"-Button geklickt. Der Übeltäter kann diesen Code in eine Webseite einfügen und den Benutzer zu deren Besuch überlisten. Bevor sich der Benutzer umsieht, hat er seine Stimme abgegeben.

In einem noch raffinierteren Ansatz wird das obige Formular in eine HTML-formatierte E-Mail eingebettet. Mehrere beliebte Mail-Clients können HTML-formatierte Mails anzeigen, und einige führen sogar den Java- Script-Code aus. Die bedauernswerten Benutzer geben also ihre Stimme (bzw. die des Angreifers) allein schon dadurch ab, dass sie ihre Mails lesen, manchmal sogar ohne zu lesen, dann nämlich, wenn das Mailprogramm ankommende Nachrichten automatisch in der Vorschau anzeigt.

Für Fortgeschrittene

Microsoft Outlook nutzt eine Internet-Explorer-Komponente (MSIE), wenn es HTML-formatierte E-Mails wiedergibt. Unter Windows 2000 vom Autor durchgeführte Tests zeigten, dass die in Outlook benutzte MSIE-Instanz alles, auch Session-Cookies, gemeinsam mit einer bereits offenen MSIE-Instanz nutzt. Sie sollten das bis zu unserem Onlinebank-Beispiel weiter unten im Auge behalten, weil es Tür und Tor für einige freche, ferngesteuerte E-Mails öffnet. (Zum Glück führen die Defaults im neueren Windows XP keine Skripte aus, die in HTML-formatierten E-Mails eingebettet sind.)

Kommentare

Bitte beachten Sie unsere Informationen zum Datenschutz.

Weitere Artikel zum Thema