Webdesign, Tutorials und mehr - Webmasterpro.de

Cross-Site Scripting

Beschreibung:

Mit Cross-Site Scripting (XSS) wird das Ausnutzen einer Computersicherheitslücke in Webanwendungen bezeichnet, indem ein Angreifer Webseiten mit clientseitigen Skripten infiziert, die von anderen Nutzern aufgerufen werden. 2007 zählte die Sicherheitsfirma Symantec das rund 80% der ausgenutzten Sicherheitslücken in Webanwendungen auf Cross-Site Scripting entfällt. Die Auswirkungen von XSS können zwischen einem kleinen Ärgernis und einem erheblichen Sicherheitsrisiko liegen, je nach Sensibilität der Daten.

Cross-Site Scripting bietet die Grundlage einer Vielzahl von anderen Angriffen, wie Session Hijacking oder Session Fixation.

Folgen:

Durch die Schwachstelle des Cross-Site Scripting ist es einem Hacker möglich, auf diese Weise Daten zu gewinnen, die zwischen dem User und der jeweiligen Website ausgetauscht werden. Der in die Webseite injizierte Code kann so dazu dienen, ein Formular anzuzeigen, um den User zu täuschen und ihn beispielsweise dazu zu bringen, Authentifizierungsinformationen einzugeben.

Des weiteren kann das injizierte Skript dazu dienen, den User zu einer vom Hacker kontrollierten Seite zu leiten, die unter Umständen gleich aussieht, wie die manipulierte Seite, um den User hinters Licht zu führen.

Funktionsweise:

XSS ist eine Art HTML Injection. Cross-Site Scripting tritt dann auf, wenn eine Webanwendung Daten annimmt, die von einem Nutzer stammen, und diese Daten dann an einen Browser weitersendet, ohne den Inhalt zu überprüfen. Damit ist es einem Angreifer möglich, auch Skripte indirekt an den Browser des Opfers zu senden und damit Schadcode auf der Seite des Clients auszuführen.

Häufig wird dabei die Übergabe von Parametern an ein serverseitiges Skript manipuliert, das eine dynamische Webseite erzeugt. Dies kann etwa das Eingabeformular einer Webseite sein, wie in Webshops, Foren, Blogs und Wikis üblich. Die eingegebenen Daten werden auf der Webseite wieder als Seiteninhalt ausgegeben, wenn die Seite von Benutzern aufgerufen wird. So ist es möglich, manipulierte Daten an alle Benutzer zu senden, sofern das Serverskript dies nicht verhindert. Diese Daten sind oft Code einer clientseitigen Skriptsprache, wie JavaScript.

Angriffsarten:

Es gibt drei grundlegende Arten von Cross-Site-Scripting-Angriffen: relexive, persistente und DOM-basierte.

Als Beispiel wird der einfache JavaScript Code alert("XSS") verwendet, jedoch kann auf die gleiche Weise auch jeder andere JavaScript Code eingeschleust werden.

Reflektives XSS:

Das nicht-persistente (non-persistent) oder reflexive (reflected) XSS ist ein Angriff, bei dem eine Benutzereingabe direkt vom Server wieder zurück gesendet wird. Enthält diese Eingabe Skriptcode, der vom Browser des Benutzers anschließend interpretiert wird, kann dort Schadcode ausgeführt werden.

Beispiel:

Eine Suchfunktion ermöglicht das Durchsuchen sämtlicher Dokumente einer Webseite. Dabei wird der Suchbegriff nochmals gesondert angezeigt („reflektiert“). Dabei würde die Anfrage in etwa so aussehen: http://www.example.com/?suche=Suchbegriff

Würde man nun als Suchbegriff <script type="text/javascript">alert("XSS")</script> eingeben, so würde der HTML Code beispielsweise so erzeugt werden:

1

<p>Sie suchten nach: <script type="text/javascript">alert("XSS")</script></p>

Nach diesem Prinzip kann auch jeglicher anderer Schadcode eingeschleust werden, allerdings muss hierbei das Opfer zuerst auf eine Webseite mit einem manipulierten Formular gelockt werden, das das Opfer dann auch nutzen muss.

Persistente Angriffe:

Persistentes (persistent) Cross-Site-Scripting unterscheidet sich vom reflexiven XSS prinzipiell nur dadurch, dass der Schadcode auf dem Webserver gespeichert wird und bei jeder Anfrage wieder ausgeliefert wird.

Beispiel:

Bietet eine Webseite ihren Nutzern an, Daten zum Beispiel durch ein Gästebuch zu speichern, kann in der Nachricht der Schadcode in der Datenbank gespeichert werden und bei jedem Aufruf wieder ausgegeben werden. Wird dazu folgendes eingetragen:

Nette Webseite!<script type=“text/javascript“>alert("XSS")</script>

würde diese bei jedem Aufruf ausgeliefert und das Skript vom Browser des Benutzers ausgeführt.

DOM-basiert oder lokal:

Im Gegensatz zu den den oben genannten gängigen XSS-Varianten, ist hier die Webapplikation auf dem Server gar nicht beteiligt. Somit sind auch an sich statische HTML-Seiten mit JavaScript-Unterstützung anfällig für diesen Angriff. Der Schadcode wird zur Ausführung direkt an ein clientseitiges Skript übergeben. Dies kann beispielsweise ein JavaScript sein, das ein URL-Argumentwert zur Ausgabe von Daten verwendet, ohne diesen ausreichend zu prüfen. Ein solcher Angriff bedarf des gezielten Aufrufs einer kompromittierten URL.

Beispiel:

Eine clientseitige Skriptsprache wie etwa JavaScript liest einen Argumentwert aus der URL aus: http://example.com/foobar.html?arg=Argumentwert

Und fügt diesen nach folgendem Schema ungeprüft in das HTML-Dokument ein:

1

<p>Sie haben an die URL diesen String angehängt: Argumentwert</p>

Wird nun die aufrufende URL folgendermaßen manipuliert: http://example.com/foobar.html?arg=<script type="text/javascript">alert("XSS")</script> würde der durch das clientseitige Skript erzeugte HTML-Code wie folgt aussehen:

1

<p>Sie haben die URL diesen String angehängt: <script type="text/javascript">alert("XSS")</script></p>

Somit würde obiges Skript im Kontext der aufrufenden Seite ausgeführt werden.

Dieses einfache Beispiel funktioniert in Firefox nicht ohne weiteres, da dieser die Zeichen einer URL in einem Link implizit kodiert. Es sind aber DOM-Injections bekannt, für die auch Firefox anfällig ist.

Gegenmaßnahmen:

Maßnahmen für Webseitenbetreiber:

Eine DOM-Injection zu verhindern, ist weit weniger einfach, da Benutzereingaben nicht serverseitig geprüft werden können. Da dieser Angriff unter Umgehung des Servers stattfindet, muss die Gültigkeitsprüfung für Eingabedaten auf Clientseite im Browser erfolgen, was allerdings wiederum leicht manipulierbar ist.

Um eine Ausgabe abzusichern (insbesondere bei reflexivem und persistentem XSS), ist es nötig, die HTML-Metazeichen durch entsprechende Zeichenreferenzen zu ersetzen, damit sie als normale Zeichen und nicht als Metazeichen behandelt werden.

Erfolgt die Ausgabe als Teil von URLs, dann muss die URL-Kodierung auf die Eingabewerte angewendet werden. Bei der Ausgabe in JavaScript-Code müssen die Zeichen mit einem umgekehrten Schrägstrich "\" maskiert werden.

Dabei ist zu beachten, dass bei diesen drei Kontexten (HTML, URL, JavaScript) unterschiedliche Zeichen eine Metafunktion haben (zum Beispiel ist "\" für HTML kein Metazeichen), es muss also immer eine an das Ausgabemedium angepasste Kodierung verwendet werden.

Die meisten Programmier- sowie Skriptsprachen verfügen über vordefinierte Funktionen zur Ersetzung der Metazeichen. Diese sollten eigenen Verfahren vorgezogen werden, da selbstentwickelte Inhaltsprüfungen weniger gut getestet und ausgereift sind.

Die Lösungsmöglichkeiten sind in den einzelnen Programmiersprachen vielfältig, wobei sie dennoch immer ein ähnliches Prinzip verfolgen. So können in Java die problematischen Zeichen ersetzt oder entschärft werden. In PHP (htmlspecialchars()) und Perl (HTML::Entities::encode_entities()) stehen entsprechende Funktionen zur Verfügung, die die problematischen HTML-Zeichen maskieren.

Maßnahmen für Webseitennutzer:

Durch Ausschalten der JavaScript-Unterstützung im Browser kann man sich gegen clientseitige XSS-Angriffe schützen. Für einige Browser gibt es auch Erweiterungen, mit denen gezielt mögliche XSS-Angriffe erkannt und verhindert werden.

Fazit:

Mit Cross-Site Scripting bietet sich dem Angreifer vielfältige Möglichkeiten um gezielt an Daten von Benutzern zu gelangen oder gezielte Angriffe auf verschiedene Webseiten zu ermöglichen. XSS bietet dadurch auch den ersten Schritt eines schwerwiegenden Angriff auf eine Webapplikation zu erreichen, die mit weiteren Angriffsmöglickeiten geknüpft werden können. Daher ist es ein absolutes Muss für jeden Webseitenbetreiber alle eingehenden Eingabewerte als unsicher zu betrachten und vor der weiteren Verarbeitung auf der Serverseite zu überprüfen.

zurück zur Übersicht Web-Sicherheit

Kommentare: Cross-Site Scripting