Web Application Security in der Praxis, Teil 2 Schutz vor Cross-Site Scripting sowie Local and Remote File Inclusion

Autor / Redakteur: Martin Dombrowski / Stephan Augsten

Neben der SQL Injection haben sich Cross-Site Scripting, Cross-Site Request Forgery sowie Local und Remote File Inclusion bei Angriffen auf Webapplikationen bewährt. Der folgende Artikel beschreibt diese verheerenden Attacken und enthält detaillierte Beispiele, die sowohl ihre Funktionsweise als auch Hintergründe verdeutlichen sollen.

Firma zum Thema

GET-Parameterübergabe des Strings ‚<script>alert(„Alarm“)</script>‘. Es öffnet sich nun ein Popup mit der Meldung „Alarm“. Dies beweist die Existenz der XSS-Schwachstelle.
GET-Parameterübergabe des Strings ‚<script>alert(„Alarm“)</script>‘. Es öffnet sich nun ein Popup mit der Meldung „Alarm“. Dies beweist die Existenz der XSS-Schwachstelle.
( Archiv: Vogel Business Media )

Wie der Name es schon vermuten lässt, handelt es sich bei Cross-Site Scripting (XSS) um den Umgang mit Skripten. Bei einer XSS-Attacke werden „fremde“ bzw. „gefährliche“ Skripte ausgeführt.

Das vermutlich bekannteste dieser Skripte liest das aktuelle Session Cookie eines angemeldeten Nutzers aus. Der Angreifer erlangt dadurch die Rechte der Benutzers und kann sich nun auf der Webseite bewegen. Diese Vorgehensweise wird Session Hijacking genannt.

Doch wie genau kann es zu einer XSS-Lücke kommen? Gehen wir zur Erläuterung von einer Webseite mit Suchfunktion aus. Nach der Suche nach einem beliebigen Begriff (zum Beispiel „Security-Insider“) wird der Anwender über das Suchergebnis informiert.

Die Ausgabe könnte zum Beispiel wie folgt lauten: „Ihre Suche nach Security-Insider ergab 3 Treffer“. Ist die Webseite nun so programmiert worden, dass sie die Ausgabe nicht nach Skriptbefehlen filtert, so werden alle Benutzereingaben interpretiert ausgegeben.

Um dies anschaulich zu erklären, folgt nun ein Sourcecode-Beispiel für eine PHP-Seite:

XSS Beispiel

Dieser Sourcecode muss nun als example.php gespeichert werden. Er kann nun Lokal oder auf einem Webserver zum Testen ausgeführt werden.

Inhalt

  • Seite 1: Wie kommt es zu XSS-Schwachstellen?
  • Seite 2: Was passiert auf dem Server?
  • Seite 3: Local und Remote File Inclusions
  • Seite 4: Cross Site Request Forgery

Was passiert auf dem Server?

Die example.php gibt nach dem Aufruf das aus, was der URL über den GET-Parameter übergeben wird. Eine mögliche GET-Übergabe des Strings „Search-Security“ würde wie folgt geschehen:

http://localhost/example.php?string=Search-Security

Wird diese URL mit Enter aufgerufen, so gibt sie den Text „Search-Security“ aus. Als nächstes übergeben wir nun Java-Skriptcode anstelle eines einfachen Text-Strings:

http://localhost/example.php?string=alert(ALARM)

Erscheint beim Aufruf dieser URL ein Popup mit dem Text „ALARM“, dann ist die PHP-Seite anfällig für eine XSS-Attacke.

Wie lässt sich diese XSS-Lücke beseitigen?

Eine Möglichkeit, die vorher beschriebene XSS-Lücke zu beseitigen, basiert auf der PHP-Funktion htmlspecialchars(). Diese Funktion wandelt Sonderzeichen in HTML-Codes um. Wendet man diese Funktion auf das vorherige Sourcecode-Beispiel an, so würde das Ergebnis wie folgt aussehen:

XSS Beispiel

Ein Aufruf dieser optimierten PHP-Seite mit einem Java-Skriptcode, der per GET-Parameter übergeben wird, lässt einen möglichen XSS-Angriff ins Leere laufen: Der Aufruf von http://localhost/example.php?string=alert(ALARM) würde alert(ALARM) als String ausgeben, und den darin enthaltenen Java-Skriptcode nicht ausführen.

Inhalt

  • Seite 1: Wie kommt es zu XSS-Schwachstellen?
  • Seite 2: Was passiert auf dem Server?
  • Seite 3: Local und Remote File Inclusions
  • Seite 4: Cross Site Request Forgery

Local und Remote File Inclusions

File Inclusions sind neben XSS weitere Schwachstellen in Webanwendungen, die es ermöglichen fremde Skripte oder Codes in das eigentliche Skript einzubinden. Sie entstehen durch unsaubere Programmierung. Es kann generell zwischen Local und Remote File Inclusions unterschieden.

  • Local File Inclusions (LFI) ermöglichen dem Angreifer lokal gespeicherte Dateien auf dem Webserver in das eigentliche Skript einzubinden. Für einen Angreifer potentiell interessante Dateien sind unter anderem Konfigurationsdateien, Schadcode oder Dateien die sensible Informationen enthalten.
  • Bei Remote File Inclusions (RFI) werden durch den Angreifer im Gegensatz zu LFI externe Skripte in das eigentliche Skript eingebunden. Dies geschieht zum Beispiel mit Hilfe von Funktionen wie include() oder require(). Im Folgenden ein kurzes Beispiel für ein verwundbares Skript für eine LFI:

Wird über den GET-Parameter Page ein Wert übergeben, so wird dieser eingebunden (http://localhost/index.php?page=user). Ist die Webanwendung verwundbar, so findet an dieser Stelle keine Überprüfung des übergebenen Parameters statt. An dieser Stelle kann nun ein Angreifer jegliche Dateien übergeben (include), wie zum Beispiel die „/etc/passwd“: http://localhost/index.php?page=../../../../../../etc/passwd

Eine Möglichkeit zur Behebung einer solchen LFI wäre die Nutzung einer Whitelist. Hierbei erstellt man ein Array mit den gewollten Seiten. Wird bei der GET-Übergabe des Page-Parameters ein vom Array abweichender String angegeben, so wird dieser durch die main.php ersetzt.

Bei einer RFI wird anstelle einer lokalen Datei eine Datei auf einem fremden Server geladen und durch das Skript ausgeführt. Ein recht oft angewandtes Beispiel ist hierbei eine sogenannte PHP-Shell. Durch dieses PHP-Skript kann der Angreifer unter anderem Shell-Befehle absetzen.

Inhalt

  • Seite 1: Wie kommt es zu XSS-Schwachstellen?
  • Seite 2: Was passiert auf dem Server?
  • Seite 3: Local und Remote File Inclusions
  • Seite 4: Cross Site Request Forgery

Cross Site Request Forgery

Beim Cross Site Request Forgery (XSRF bzw. CSRF) versendet der Anwender unwissentlich Befehle an eine Webanwendung. Hierfür schickt ein Angreifer dem Nutzer einen Link, der entsprechende Befehle enthält. Solche URLs lassen sich zum Beispiel durch URL-Shortener-Dienste (tinyurl.com, bit.ly etc.) verkürzen und werden eher vom Anwender angeklickt.

Im folgenden Beispiel würde das Anklicken des besagten Links einen neuen Anwender in der Webanwendung Beispiel.de erstellen:

http://www.beispiel.de/user.php?action=new_user&name=badboy&password=geheim

Fazit

Es ist festzuhalten, dass obwohl diese beschriebenen Schwachstellen seit langem Bekannt sind, diese jedoch noch recht oft vorkommen. Hierbei reichen zumeist einfachste Mechanismen um schon bei der Entwicklung der Webanwendungen dafür zu sorgen, dass es nicht zu solchen Schwachstellen kommt.

Inhalt

  • Seite 1: Wie kommt es zu XSS-Schwachstellen?
  • Seite 2: Was passiert auf dem Server?
  • Seite 3: Local und Remote File Inclusions
  • Seite 4: Cross Site Request Forgery

(ID:2049815)