entwickler.com

In dieser Folge erfahren Sie, wie Angreifer den in About Security #14 vorgestellten Cross-Site-Scripting-Code einschleusen und Entwickler dessen Ausführung verhindern können.

Code einschleusen

Es gibt drei Möglichkeiten, um Parameter von einem Webbrowser an eine Webanwendung zu übertragen:
Ein Formular kann Eingaben über die POST- oder die GET-Methode schicken. Bei der POST-Methode baut der Webbrowser eine Verbindung zum für die Formularverarbeitung zuständigen Server auf und sendet in einem zweiten Schritt die Daten. Bei der GET-Methode werden die Daten, abgetrennt durch ein '?', an den im action-Attribut des Formulars definierten URL angehängt und so an den Server gesendet. Cookies werden vom Webbrowser verwaltet und bei jedem Request an den entsprechenden Webserver mitgesendet.

Ein Angreifer kann alle drei Methoden verwenden, um Code einzuschleusen. Üblich ist der Weg über die GET-Methode, da dafür nur ein URL entsprechend präpariert und dem Opfer untergeschoben werden muss. Um über die POST-Methode Code einzuschleusen, muss das vom Benutzer verwendete Formular manipuliert werden. Ein Einschleusen über Cookies ist im Allgemeinen zu aufwändig, da der Angreifer die Cookies im Webbrowser seines Opfers oder auf dem Übertragungsweg manipulieren muss.

Ein Angriff ist auch über Daten möglich, die nicht direkt an den Benutzer zurückgegeben, sondern vorher in einer Datenbank gespeichert wurden. Dies betrifft zum Beispiel Einträge in Gästebüchern, Kommentaren oder ähnlichem. Dort eingeschleuster Code wird im Browser des Benutzers ausgeführt, wenn ein entsprechend präparierter Eintrag betrachtet wird. Der Vorteil für den Angreifer bei diesem so genannten Persistenten Cross-Site Scripting: Er kann problemlos auch die POST- und Cookie-Parameter zum Einschleusen verwenden, da er die Daten selbst an den Server sendet. Nutzt er die direkte Rückgabe von Eingaben aus, muss er den Benutzer die manipulierten Daten senden lassen. Derartige Angriffe werden auch als reflektiertes Cross-Site Scripting bezeichnet.

Alle Eingaben müssen daher vor der Rückgabe an den Benutzer, beziehungsweise vor der Speicherung in einer Datenbank, sorgfältig auf Cross-Site-Scripting-Code geprüft werden. Besonders ist darauf zu achten, dass auch wirklich alle verwendeten Parameter geprüft werden. Niemand kann einen Angreifer daran hindern, einen bestimmten Parameter sowohl über die GET- als auch über die POST-Methode an die Webanwendung zu senden. Wird dann der eine Parameter geprüft und der andere (ungeprüfte) verwendet, kann Code an der Schutzfunktion vorbeigeschleust werden.

Dies war z.B. die Ursache für einige SQL-Injection-Schwachstellen in Cacti: Für SQL-Abfragen wurden mit GET übertragene Parameter verwendet. Geprüft wurde jedoch die Variable , in die der Reihe nach die Inhalte der GET-, POST- und Cookie-Parameter geschrieben werden. Ein Angreifer konnte so seinen Code mit GET und einen harmlosen Wert mit POST oder als Cookie senden, um die Schutzfunktion zu umgehen.

Codeausführung verhindern

Das Verhindern der Codeausführung ist sehr einfach, wenn generell kein vom Benutzer eingegebener HTML-Code ausgeführt werden soll: Eingegebener HTML-Code wird gelöscht oder unbrauchbar gemacht. Für PHP erledigen dies die Funktionen strip_tags() und htmlspecialchars() oder htmlentities(). Während strip_tags() versucht, alle HTML-Tags zu löschen, wandeln htmlspecialchars() und htmlentities() bestimmte oder alle Zeichen in die entsprechenden HTML-Entities um. Aus den Zeichen '<' und '>' zur Kennzeichnung von HTML-Tags werden so die entsprechenden HTML-Entities '<' und '>'. Wird die so bearbeitete Eingabe an den Webbrowser zurückgegeben, werden die HTML-Tags nicht interpretiert, sondern als Text ausgegeben.

Ähnliche Funktionen stehen auch für Perl (im CPAN-Modul HTML::Entities) und ASP.NET zur Verfügung. Bei Bedarf kann eine Funktion zum Unbrauchbarmachen auch schnell selbst geschrieben werden. Die Zeichen '<', '>', '&' und '"' sollten durch die entsprechenden HTML-Entities '<', '>', '&' und '"' ersetzt werden.

Schwieriger wird es, wenn die Eingabe bestimmte HTML-Tags enthalten darf, beispielsweise weil in einem Gästebuch oder Forum bestimmte Hervorhebungen möglich sein sollen. In diesem Fall müssen unerwünschte Tags ausgefiltert werden, die erwünschten Tags dürfen jedoch nicht beschädigt werden. Erschwert wird dies durch verschiedene Zeichenkodierungen und die Eigenheiten mancher Webbrowser, auch fehlerhaften HTML- oder JavaScript-Code zu interpretieren. Dadurch steigt die Gefahr, dass eingeschleuster Cross-Site-Scripting-Code nicht als solcher erkannt wird. Entsprechende Filterfunktionen müssen meist selbst geschrieben werden. Dabei sollten alle zulässigen Tags festgelegt und alle anderen gelöscht oder unbrauchbar gemacht werden. Werden gezielt die unzulässigen Tags ausgefiltert, können gefährliche Tags übersehen werden.

Weitere Informationen zu Cross-Site Scripting erhalten Sie ab Folge #129. In der nächsten Folge geht es um das Einschleusen von Skriptcode in Webanwendungen.

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
• 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