entwickler.com

Welche Schwierigkeiten es beim in About Security #21 vorgestellten HTTP Response Splitting gibt, erfahren Sie in dieser Folge.

HTTP Response Splitting ist immer dann möglich, wenn nicht korrekt gefilterte Benutzereingaben Bestandteil von HTTP-Responses werden. Außer in den bereits erwähnten Fällen der Redirection Responses und des Setzens von Cookies kann dies auch bei den von einigen Webservern unterstützten individuellen Skripten zur Fehlerbehandlung passieren. Außerdem können Webanwendungen die HTTP-Responses durch in den meisten APIs vorhandene Funktionen beliebig manipulieren.

Behandlung der Benutzereingaben

Die Ausnutzung einer Schwachstelle scheitert unter Umständen an der Behandlung der Eingaben. Manche API-Funktionen filtern CR- und LF-Zeichen aus, erzeugen eine Fehlermeldung oder URL-kodieren die Eingabe.

Die Eingaben können auch automatisch verändert werden, wenn bestimmte Zeichen darin vorkommen. Zum Beispiel interpretiert ASP.NET 1.0/1.1 die Daten als UTF-8 und ignoriert Zeichenketten, die in UTF-8 ungültig sind. Das Zeichen <, gefolgt von einem alphanummerischen Zeichen, wird von ASP.NET 1.1 nicht akzeptiert usw.

Für die manipulierten Header werden nur harmlose ASCII-Zeichen benötigt. Problematisch ist der Response Body. Wird das Ergebnis im Internet Explorer angezeigt, kann der Body in UTF-7 kodiert werden. Dadurch wird jedes Unicode-Zeichen zu einer Folge von ASCII-Zeichen. Danach besteht keine Gefahr mehr, dass die Daten umkodiert werden oder einen Fehler verursachen.

Zu lange URLs

In manchen Fällen wird eine sehr lange HTTP-Response benötigt. Bei einem Angriff über HTTP-GET-Requests kann der dafür nötige lange URL zu Problemen führen, da manche beteiligte Systeme zu lange URLs zurückweisen. HTTP-POST-Requests sind davon nicht betroffen, da die Daten dort im Request Body übertragen werden. Ist ein URL für einen GET-Request zu lang, kann stattdessen oft ein POST-Request verwendet werden, da die Webanwendung nicht zwischen beiden Methoden unterscheidet. Ist dies nicht möglich, können die Daten eventuell in mehreren Headern übertragen und/oder so kodiert werden, dass nach einer Umkodierung durch den Webserver oder die Webanwendung die nötige Länge erreicht wird. Zum Beispiel wird ein vom Angreifer gesendetes " zu ", wenn der Webserver es für den Response Body als HTML Entity kodiert – aus einem Byte werden sechs.

Erkennen der zweiten HTTP-Response

Für einen erfolgreichen Angriff muss das Angriffsziel (Cacheserver oder Webbrowser) zwei HTTP-Responses erkennen. Dies ist nicht so selbstverständlich, wie es nach dem Beispiel in About Security #21 aussieht. Der Erfolg hängt davon ab, wie die Antwort interpretiert und das Ende bzw. der Anfang einer HTTP-Response erkannt werden. In folgenden drei Fällen konnten HTTP-Response-Splitting-Angriffe erfolgreich durchgeführt werden (Amit Klein, "Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics", (PDF)):

• Erkennung an Nachrichtengrenzen: Die zweite Nachricht beginnt direkt nach dem Ende der ersten. In diesem Fall funktioniert der Angriff aus dem Beispiel in About Security #21.
• Erkennung an Puffergrenzen: Die erste Nachricht wird stückweise in einen Puffer fester Länge kopiert. Nach der Verarbeitung der Nachricht werden alle Teile einschließlich des letzten verworfen. Dabei kann der letzte Teil Daten enthalten, die logisch zur nächsten Nachricht gehören. In diesem Fall funktioniert das Beispiel nicht. Die Daten müssen so angepasst werden, dass die Länge der ersten HTTP-Response ein Vielfaches der Pufferlänge beträgt.
• Erkennung an Paketgrenzen: Die Nachrichten werden paketweise gelesen. Die Reste des letzten Pakets der ersten Nachricht werden ignoriert, der Beginn der zweiten Nachricht wird im nächsten Paket erwartet. Abhängig vom Timing können zusätzliche Response-Daten ignoriert werden, bis der zweite Request verarbeitet wurde. Für einen erfolgreichen Angriff müssen sowohl die Aufteilung in Pakete als auch das Timing stimmen.

Vergiften von Webcaches

Die vergiftete HTTP-Response muss meist einen Last-Modified-Header mit einem Datum in der Zukunft enthalten, um gecached zu werden. Beim Vergiften von Browser-Caches kommen weitere Anforderungen hinzu: Da der Browser einen If-Modified-Since-Header in seinem Request mitschickt, muss der Angreifer sicherstellen, dass der Server mit dem HTTP-Status 304 (Unmodified) antwortet. Außerdem muss die angeforderte Ressource existieren und cachebar sein. Beim Vergiften von Cacheservern ist die Situation einfacher, da diese Browser-Requests nur an den Webserver weiterleiten, wenn sie explizit dazu aufgefordert werden oder der Cacheinhalt veraltet ist. Auch können auf dem Webserver nicht existierende Ressourcen vergiftet werden.

Einige Proxy-Server aktualisieren ihren Cache in regelmäßigen Abständen, indem sie die Requests direkt an den Webserver weiterleiten. In diesem Fall muss der Angreifer seinen Angriff regelmäßig wiederholen, um seine vergifteten Daten in den Cache zu schreiben.

Nachdem die Grundlagen und Schwierigkeiten des HTTP Response Splittings beschrieben wurden, geht es in der nächsten Folge um die praktische Durchführung eines solchen Angriffs.

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