Mittwoch, 22. August 2012


Topthema

Donnerstag, 8. September 2005 | Topthema

About Security #22: HTTP Response Splitting, 2

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/023968)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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
About Security: Die komplette Serie

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 &quot;, 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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren