Cross Site Scripting

aus HaBo WiKi, der freien Wissensdatenbank von http://www.hackerboard.de
(Weitergeleitet von XSS)
Wechseln zu: Navigation, Suche
Heutzutage sind Webseiten komplexer als jemals zuvor. Immer mehr Webseitenbetreiber setzen dabei auf dynamische Inhalte, die es dem User ermöglichen sollen schneller und besser an Informationen zu gelangen oder gar eine Seite an die persönlichen Bedürfnisse anzupassen. Doch dynamische Webseiten können, im Gegensatz zu statischen Webseiten, Sicherheitsrisiken und Angriffsfläche beherbergen, die vom Betreiber oft erst bemerkt werden, wenn der Webseite oder seiner Besucher bereits Schaden zugefügt wurde.
Eine dieser Gefahren nennt sich Cross Site Scripting.



Cross Site Scripting wird meist mit XSS abgekürzt. In seltenen Fällen wird als Abkürzung auch CSS verwendet. Hier droht die Verwechslung mit "Cascading Style Sheets", was damit absolut nichts zu tun hat.

Vorgehensweise

Gewöhnlich wird der bösartige Code über einen Link, welcher strategisch platziert wurde, übergeben. Dadurch, dass der Link meist offensichtlich zu einer vertrauenswürdigen Seite führt, folgt ein User nichts ahnend diesem Link. Er findet diesen Link auf einer anderen Webseite, in einer Nachricht die er per Instant Messaging erhalten hat oder einfach oft in einer Email, Diskussionsboard oder Gästebuch. Gewöhnlich codiert der Angreifer den Code im Link durch Verwendung von HEX oder anderer Methoden, damit der User keinen Verdacht schöpft. Nachdem die Daten an die fehlerhafte Webapplikation auf der manipulierten Webseite übergeben wurden, wird eine Ausgabeseite generiert, auf welcher nun der übergebene bösartige Code ausgeführt wird. Dabei wird das Script oft als gültiger Inhalt der Seite getarnt, so dass der User dieses nicht weiter wahrnimmt. Diese Vorgehensweise weist parallelen zu der des Computer Based Social Engineerings auf.

Gefahren

Clientseitig

Oft schleusen Angreifer JavaScript, VBScript, ActiveX, HTML, oder Flash ein, um User zu schädigen. Dadurch, dass dieser Code clientseitig, also auf dem Rechner des Users, ausgeführt wird, droht eine Vielzahl an Gefahren. Angefangen von "Account Hijacking", also das Übernehmen eines Benutzeraccounts, Ändern von Benutzereinstellungen, Manipulation oder Diebstahl von Cookies, Installieren von Malware, bis zur Änderung und Beeinflussung des auf einer Webseite angezeigten Inhaltes ist so gut wie alles denkbar.

Serverseitig

Unter gewissen Vorraussetzungen und nicht selten unter Zuhilfenahme eines Bugs in der Serversoftware ist es möglich fremden Code einzubinden, welcher serverseitig ausgeführt wird. Durch Manipulation einer Variablen könnte beispielsweise erreicht werden, dass in einem PHP Script eine fremde Datei included wird. Neuerdings werden auch Webspider missbraucht um serverseitige XSS-Attacken auszuführen. Hierzu wird ein präparierter Link auf einer Webseite veröffentlicht welchem ein Webspider wie z.B. der Googlebot dann folgt. Dadurch taucht die IP-Adresse des Spiders in den Logs auf und der eigentliche Angreifer bleibt unerkannt.


Beispiele

Die folgenden Beispiele beziehen sich zwar ausschließlich auf PHP, XSS ist jedoch in allen serverseitigen Scriptsprachen möglich.

PHP_SELF

PHP-Entwickler nutzen aus Bequemlichkeit oft die Variable $_SERVER['PHP_SELF'] um in Formularen die aktuelle Adresse in das Form-Tag schreiben zu lassen. In nahezu jeder dynamischen Webseite werden Formulare verwendet, beispielsweise in einem Gästebuch, Board, Shopsystem oder auch nur in einem Kontaktformular. Die Verwendung von $_SERVER['PHP_SELF'] birgt jedoch eine Gefahr von XSS in sich.

Der folgende Code stellt ein typisches Beispiel dar.

<form action="<? echo $_SERVER['PHP_SELF']; ?>" method="post">

Nehmen wir an hierbei handelt es sich um ein Kontaktformular welches per http://host/contact.php zu erreichen ist. PHP würde nun automatisch "contact.php" in das Form-Tag schreiben. Was aber passiert, wenn man die URL manipuliert?

In diesem Beispiel wird ein simples Javascript, welches eine Alert Box aufruft, in die Seite eingeschleust. Dazu genügt es den Code an das Ende der URL zu hängen. Würde diese Seite nun über einen Link per folgender URL aufgerufen werden: http://host/contact.php/"><script>alert('XSS')</script><form="

erzeugt PHP folgende Ausgabe:

<form action="contact.php/"><script>alert('XSS')</script><form="" method="post">

Somit würde der Scriptcode zur Ausführung kommen. Möglich wird dies, da die aktuelle Adresse des Scripts ungefiltert ausgegeben wird. Es findet nirgendwo eine Überprüfung der Validität der übergebenen Adresse statt. Durch dass neu entstandene zweite Form-Tag werden zusätzlich Code-Teile, die nun nicht mehr richtig Dargestellt werden würden, ausgeblendet. Der ahnungslose Besucher bekommt von all dem nichts mit.


Doch hier verbirgt sich noch eine weitere Gefahr. Das Umleiten eines Logins. Dadurch das hier direkt das Form Tag verändert wird, ist es sehr einfach möglich sich ein eigenes Form Tag zu erstellen. Dieses würde nach dem originalen angezeigt werden, mit der Folge, dass das originale durch den Browser ignoriert wird. Damit kann ein Angreifer, durch einen User angegebene Login-Daten, zu sich weiterleiten. Dies könnte z.B. bei Onlinebanking fatale Folgen haben.


Suchfunktion

Viele dynamische Webseiten besitzen eine Suchfunktion um es dem Besucher zu erleichtern bestimmte Informationen zu finden. Genau diese gut gemeinte Funktion kann jedoch Angriffsfläche für einen XSS-Angriff bieten.

Das folgende Beispiel orientiert sich an der Realität einer großen deutschen Nachrichtenseite, dessen Betreiber Sicherheitshinweise seit geraumer Zeit ignoriert.

Betrachten wir zunächst den Code der PHP Datei.

<?php
if ($_GET['query']) {
$suchergebnis=stripslashes($_GET['query']);
echo "Folgende Suchergebnisse wurden zum Begriff $suchergebnis gefunden:";

// ...
}
?>

<form action="suche.php" name="suche" method="get">
<input value="Begriff" name="query" type="text">
<input value="Suche" type="submit">
</form>

Die Suche wird per http://host/suche.php aufgerufen. Nach dem Absenden wird der Suchbegriff per GET übergeben und ungefiltert auf der Ergebnisseite ausgegeben. Hinzu kommt, das Slashes entfernt werden, um das Suchergebnis korrekt auszugeben. Durch diese Unachtsamkeit ist es abermals möglich, Code einzuschleusen. Beispiel: http://host/suche.php?query=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%27%58%53%53%27%29%3b%3c%2f%73%63%72%69%70%74%3e


Änderung des Contents

Gerade bei Auktionen werden oft bestimmte Daten wie z.B. die Bewertung des Verkäufers per Javascript angezeigt. Sollte es nun möglich sein ein eigenes Javascript einzuschleusen, ließen sich diese Daten manipulieren. Vorausgesetzt, der Besucher folgt einem Link der sich nicht auf der Originalseite befindet oder der Auktionsdienst erlaubt das Einbinden von Code direkt in die Auktionsseite. Eine weitere Möglichkeit stellt das Anzeigen eines gefakten Login-Formulars oder Installieren von Malware dar.


Diebstahl eines Cookies

Sehr beliebt ist es, mittels XSS, Cookies zu stehlen um Benutzeraccounts zu übernehmen. In der Vergangenheit wurden z.B. immer wieder in verschiedenen Boards Bugs gefunden, die dies ermöglichen. Gefährdet sind aber generell alle Dienste die auf die Verwendung von Benutzeraccounts zurückgreifen. Auch hier wird entweder der Inhalt einer übergebenen Variable manipuliert oder aber bösartiger Scriptcode z.B. in ein Posting eingebaut oder bei der Registrierung an den Benutzernamen gehängt, da vor dem Abspeichern in der Datenbank oder aber spätestens bei der Ausgabe der Inhalt nicht ordnungsgemäß geprüft wurde. Wird dann eine entsprechende Seite aufgerufen, die den Inhalt darstellt, wird für den User unsichtbar, im Hintergrund das Script ausgeführt und der Inhalt des Cookies des Users an den Angreifer übermittelt. Mit den Daten aus dem Cookie kann sich der Angreifer dann bequem einloggen und den Account übernehmen. Besonders heikel wird das Ganze, wenn es sich um den Account eines Moderators oder Administrator handelt, da er über weit reichende Rechte verfügt.

Code includen

Der folgende serverseitige XSS-Angriff setzt eine schlechte Konfiguration von PHP auf dem Webserver voraus. (URL fopen wrappers aktiviert und register_globals deaktiviert)

Dieses Beispiel demonstriert eine PHP Seite, in die per Navigations-Link eine andere PHP Datei includet wird. Der Aufruf der Seite sieht wie folgt aus http://host/index.php?site=members.php

Und hier folgt der entspr. Code dazu:

<?php
 include($site); 
?>

Würde man nun anstatt members.php eine URL zu einem bösartigen Script übergeben, was beispielsweise die Daten für einen Datenbankzugriff ausliest, würde dieser fremde Code ausgeführt werden.


Missbrauch einer SQL Abfrage

Häufig kommt es vor, das Variablen, die per GET übergeben werden, direkt in SQL Queries Verwendung finden.

Ein Aufruf könnte so aussehen: http://host/login.php?user=User123

Ein entspr. Code dazu:

SELECT * FROM members WHERE username='$_GET['user']' 

Auch hier ließe sich Code einschleusen. Siehe dazu den Artikel SQL_Injection.

Schutzmaßnahmen

Viele Webseitenbetreiber ignorieren die Gefahr durch XSS weil sie sein Potential unterschätzen. Doch es bedarf nur etwas Fantasie um sich entsprechende Angriffsszenarien auszumalen.

Entwickler

Regel Nr. 1 für Entwickler lautet: Vertraue niemals Usereingaben. Alle eingehenden Daten sind potentiell gefährlich. Alle Variablen die Usereingaben enthalten können und alle Variablen die ausgegeben werden, sollten gefiltert und auf enthaltenen Code geprüft werden. Ein guter Anfang ist es Zeichen wie <>()&#;'" in die entsprechenden HTML Entities umzuwandeln oder ganz auszuschneiden. Alle Scriptsprachen stellen entspr. Funktionen bereit, mit denen dies einfach umzusetzen ist. Beispiele für PHP findet man hier: http://de3.php.net/htmlentities Auf keinen Fall sollte man den Fehler machen, zu meinen, durch ein simples Verbot des <script> Tags Sicherheit schaffen zu können. Dem ist nicht so! Es gibt unzählige Möglichkeiten Code zur Ausführung zu bringen. Siehe dazu http://ha.ckers.org/xss.html

Die Verwendung von SSL kann nicht vor XSS schützen, da ein Verschlüsseln der Verbindung nicht die Ausführung einer Web-Applikation beeinflusst!

User

Ein User hat nur wenige Möglichkeiten sich vor XSS zu schützen. Der beste Schutz ist eine gesunde Skepsis gegenüber Links die auf fremden Seiten oder von fremden Personen in Boards oder Gästebüchern gepostet wurden. Ein User sollte beispielsweise anstatt einem Link zu einem interessanten Ebay-Angebot auf einer "3rd-Party-Seite" zu folgen, Ebay direkt aufrufen und dort nach dem Angebot suchen. Auch ein Deaktivieren von Javascript im Browser kann keinen Schutz garantieren.


Prominente Opfer

Es ist keineswegs so, dass diese XSS-Anfälligkeit nur kleine, durch Amateure erstellte Seiten betrifft. Eine Liste an betroffenen Seiten hätte die Länge dieses Artikels und kaum ein großes Unternehmen wäre nicht zu finden. Darunter Ebay, Google, Yahoo, Overture, AOL, CNN, Adobe, Amazon, Microsoft, Mozilla, SUN, NASA, Oracle, Paypal ... Viele dieser Lücken sind mittlerweile gefixt doch einige Unternehmen wollen das Risiko, welches davon ausgeht scheinbar nicht für voll nehmen. Meistens wachen sie erst dann auf, wenn sie bereits in den Medien "zerrissen" werden und schlechte Publicity droht, da sie z.B. als Wirt für Phishing herhalten müssen und bereits massenhaft Kunden durch Links in gefälschten Emails, die zu gefakten Login-Formularen führen, geschädigt wurden.

Weiterführende Links