News Drucken: About Security #17: HTTP Request Smuggling

Ab dieser Folge lernen Sie eine neue Sorte von Angriffen gegen Webserver kennen: HTTP-Request-Smuggling. Dieses Verfahren wurde zuerst von Watchfire beschrieben (PDF).

Die Ursachen

Der Angriff basiert darauf, dass mehrere an der Übermittlung eines HTTP-Requests beteiligte Systeme (z.B. Cache- oder Proxy-Server, Firewalls) widersprüchliche bzw. inkonsistente Header-Einträge unterschiedlich interpretieren. Bei einem Angriff werden mehrere speziell präparierte HTTP-Requests gesendet, die von den beteiligten Systemen unterschiedlich interpretiert werden. Mögliche Folgen sind das Vergiften von Web-Caches, Request Hijacking, Cross-Site Scripting und die Täuschung von Firewalls und Intrusion-Detection- bzw. Prevention-Systemen.

Vergiften des Webcaches

Befindet sich ein Webcache/Proxy-Server zwischen Client und Webserver, kann ein Angreifer den Cache so manipulieren, dass eine existierende und cachebare Seite A unter der URL B gespeichert wird. Ruft ein Client danach die Seite B auf, wird der Inhalt der Seite A zurückgeliefert.

Beim Angriff wird ein POST-Request mit zwei 'Content-Length'-Headern mit unterschiedlichen Werten verwendet. Einige Server, z.B. IIS und Apache, weisen derartige Requests ab. Andere akzeptieren sie und ignorieren den problematischen Header. Dabei fällt die Entscheidung, welcher Header ignoriert wird, von Server zu Server verschiedlich aus. So verwendet der SunONE Webserver 6.1 (SP1) den ersten 'Content-Length'-Header, während der SunONE Proxy 3.6 (SP4) diesen ignoriert und den zweiten verwendet.

Im folgenden Beispiel (nach obigen Whitepaper) ist WEBSITE der Name des SunONE Webservers hinter dem SunONE Proxy. gift.html ist eine statische (cachebare) HTML-Seite auf dem Webserver, ziel.html die zu vergiftende Seite. Dies ergibt folgende Requests:

   1  POST http://WEBSITE/irgendwas.html HTTP/1.1   
   2  Host: WEBSITE   
   3  Connection: Keep-Alive    
   4  Content-Type: application/x-www-form-urlencoded   
   5  Content-Length: 0   
   6  Content-Length: 52   
   7  [CRLF]   
   8  GET /gift.html HTTP/1.1   
   9  Host: WEBSITE   
  10  Wegdamit: 
  11  GET http://WEBSITE/ziel.html HTTP/1.1   
  12  Host: WEBSITE   
  13  Connection: Keep-Alive   
  14  [CRLF]

Jede Zeile mit Ausnahme der 10. endet mit einem CRLF ("\r\n"). Der HTTP-Standard (RFC 2616) definiert CRLF als Kennzeichnung für das Zeilenende. In Zeile 10 befindet sich ein Leerzeichen hinter "Wegdamit:", aber kein CRLF. Da der SunONE Proxy Requests aus dem gleichen Paket nicht nacheinander ausführt, müssen die Zeilen 1 bis 10 und 11 bis 14 in zwei getrennten Paketen gesendet werden.

Werden diese Requests vom Client über den Proxy an den Webserver gesendet, passiert Folgendes:

Der Proxy-Server parst den POST-Request in Zeile 1 bis 7 und findet zwei 'Content-Length'-Header. Der erste wird ignoriert, sodass er von einem Body der Länge 52 Bytes ausgeht. Dadurch werden die Zeilen 8 bis 10, die 52 Bytes enthalten, als Body des ersten Requests betrachtet. Danach wird der GET-Request in Zeile 11 bis 14 geparst und als zweiter Request des Clients betrachtet
Der Webserver interpretiert die vom Proxy-Server weitergeleiteten Daten folgendermaßen: Von den beiden 'Content-Length'-Headern des POST-Requests in Zeile 1 bis 7 wird der erste verwendet. Dadurch hat der erste Request keinen Body und als zweiter Request wird der GET-Request ab Zeile 8 verwendet. Das GET in Zeile 11 wird aufgrund des fehlenden CRLF in Zeile 10 als Wert des 'Wegdamit:'-Headers in Zeile 10 betrachtet.

Damit ergibt sich folgende Aufteilung der Daten:

	1. Request:	2. Request:
Proxy	Zeilen 1-10	Zeilen 11-14
Webserver	Zeilen 1-7	Zeilen 8-14

Welche Daten werden an den Client zurückgeliefert?

Der Webserver sieht ein POST /irgendwas.html in Zeile 1 und ein GET /gift.html in Zeile 8. Er sendet also zwei Antworten mit dem Inhalt der Seiten /irgendwas.html und /gift.html.
Der Proxy-Server ordnet diese Antworten den Requests zu, die er vom Client empfangen hat: POST /irgendwas.html in Zeile 1 und GET /ziel.html in Zeile 11. Da die Antwort cachebar ist, speichert er den Inhalt von /gift.html unter der URL /ziel.html und vergiftet damit den Cache: Jeder Client, der die Seite /ziel.html vom Proxy anfordert, erhält den Inhalt von /gift.html zurück.

Der Angreifer kann somit cachebare Seiten einer Website durch andere Seiten der gleichen Site ersetzen. Teilt sich die angegriffene Website die IP-Adresse mit einer Site unter der Kontrolle des Angreifers, wie es in Shared-Hosting-Szenarien möglich ist, kann durch einen entsprechenden Host-Header in Zeile 9 ('Host: boese-site') eine Seite des Angreifers untergeschoben werden. Ähnliches ist durch die Verwendung eines Proxy-Requests in Zeile 8 möglich: 'GET http://boese-site/seite.html ...'

Das oben vorgestellte Vergiften eines Webcaches ist nur einer von mehreren möglichen Angriffen über HTTP-Request-Smuggling. In der nächsten Folge werden zwei weitere Angriffe über HTTP-Request-Smuggling beschrieben: Request Hijacking und Request Credential Hijacking.

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"