Cross-Site Scripting

14. Juli 2011
Von

Cross-Site-Scripting (kurz XSS) ist wohl einer der häufigsten Angriffe auf Webapplikationen überhaupt. Obwohl das Prinzip altbekannt ist, tauchen immer wieder neue Seiten im Netz auf, die entweder nicht gegen JavaScript-Manipulationen geschützt sind oder eben dieses Verfahren unterschätzen.

Im Prinzip sind XSS-Angriffe immer gleich aufgebaut: Über eine Lücke in der Parameterüberprüfung versucht der Angreifer seinen eigenen JavaScript-Code einzuschleusen, der anschließend auf dem Clienten ausgeführt wird.

Ein einfaches Beispiel:

<!-- Der Benutzer soll seinen Namen eingeben und wird begrüßt -->
<form action="" method="POST">
Name: <input type=“text“ name=“user“ />
<input type=“submit“ name=“greeting“ value=“Grüße mich!“ />
</form>
<?php
if (isset($_POST['user']))
{
	//Formularinhalt ungefiltert ausgegeben
	echo „Hallo “.$_POST['user'].“!“;
}
?>

Daten, die im vorherigen Formular eingegeben werden, werden anschließend ungefiltert über den ECHO-Befehl ausgegeben. Gibt ein Angreifer also anstelle seines Namens ein JavaScript-Code ein, so wird dieser ausgeführt, beispielsweise:

<script>alert('Dies ist ein XSS-Test');</script>

Schon wäre ein erster XSS-Angriff gelungen; allerdings ein sehr kleiner, zugegebenermaßen. Jedoch wäre der Angreifer nun zumindest um die Erkenntnis reifer, dass an dieser Stelle eine JavaScript-Code-Einschleusung möglich ist.

Gefährlich ist dieses Beispiel natürlich noch für keine Seite – schlussendlich wird der Code ja nur auf dem Rechner des Angreifers selbst ausgeführt. Anders verhält es sich dagegen, wenn noch eine Datenbankanbindung besteht: Schafft es der Angreifer beispielsweise in einem Forum, XSS-Code innerhalb seines Beitrages zu platzieren, so wird dieser bei jedem Betrachten des Beitrages interpretiert – und auf denjenigen Benutzer angewandt, der gerade dann unschuldig durchs Forum surft.

Solch ein JavaScript-Code würde natürlich im seltensten Fall ein simples ALERT-Fenster aufrufen. Dagegen ist es wahrscheinlicher, dass der Angreifer jeden Forennutzer zum Beispiel auf eine andere Seite weiterleitet (ggf. sogar kombiniert mit einem Phishing-Angriff!) oder versucht, die benutzereigenen Cookies auszulesen (unter Umständen sogar hilfreich bei einem Session-Diebstahl, der sehr gefährliche Auswirkungen haben kann).

Auch wenn es auf dem ersten Blick also ungefährlich scheint, können XSS-Angriffe sehr stark sein und sollten niemals unterschätzt werden.

Verhältnismäßig einfach ist dagegen der Schutz gegen XSS. Gemäß dem Leitsatz „Vertraue nie Eingaben, die vom Benutzer kommen!“ hilft eine gute Parameterüberprüfung vor möglicher Manipulation.

So ist es angebracht, sämtliche Benutzereingaben vor der Verwertung (speichern in Datenbank, Ausgeben, ..) von allen HTML-Tags durch die PHP-Funktion strip_tags() zu bereinigen. Um im Anschluss noch zu verhindern, dass Angreifer ihr HTML manipulieren, muss auf die Benutzereingaben htmlentities() angewandt werden. Die PHP-interne „Magic Quotes“ reichen nicht aus und sind -abgesehen davon- als DEPRECATED markiert.

Eine Absicherung des obigen Beispiels gegen XSS-Angriffe würde also so aussehen:

<!-- Der Benutzer soll seinen Namen eingeben und wird begrüßt -->
<form action="" method="POST">
Name: <input type=“text“ name=“user“ />
<input type=“submit“ name=“greeting“ value=“Grüße mich!“ />
</form>
<?php
if (isset($_POST['user']))
{
	$strip = strip_tags($_POST['user']);
	$gegenXSS = htmlentites($strip, ENT_QUOTES);
	//Formularinhalt gefiltert ausgegeben
	echo „Hallo “.$gegenXSS.“!“;
}
?>

Tags: , , ,

One Response to Cross-Site Scripting

  1. Tobsen zu 15. August 2011 auf 07:22

    Auch wieder ein ausführliches Beispiel, wie so ein XSS Angriff aussehen könnte. Ich hör zwar immer davon, aber so richtig vorstellen können, tue ich es mir dann doch nicht.

Hinterlasse einen Kommentar zu Tobsen Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.

Finde mich auf

Werbung