entwickler.com

Was HTTP Request Smuggling ist und was ein Angreifer damit erreichen kann, wissen Sie inzwischen. In dieser Folge erfahren Sie, wie man HTTP Request Smuggling erkennen und verhindern kann.

Wie in den letzten Folgen zu sehen war, kann man die Angriffe z.B. an doppelten Headern mit unterschiedlichen Werten erkennen. Das Problem dabei: Die Firewall bzw. das Intrusion-Detection-/Prevention-System bekommt diese Header unter Umständen gar nicht in diesem Zusammenhang zu sehen. Also muss nach einer anderen Methode gesucht werden, um die Angriffe zu erkennen.

HTTP Request Smuggling erkennen

Amit Klein hat ein Verfahren beschrieben, das die Angriffe auf TCP-Ebene erkennen kann. Das Verfahren nutzt das TCP-PSH-Bit und -PUSH-Flag. Laut RFC 793, in dem das Transmission Control Protocol definiert wird, haben diese folgende Bedeutung: Die push-Funktion stellt sicher, dass alle übergebenen Daten sofort übertragen werden. Wird das PUSH-Flag in einem SEND-Aufruf gesetzt, werden alle Daten des aktuellen Aufrufs und der vorhergehenden Aufrufe sofort an den Empfänger übertragen. Realisiert wird dies durch das PSH-Bit im TCP-Header.

RFC 793 schreibt vor, dass das Socket API die Möglichkeit bietet, das PSH-Bit über das PUSH-Flag in der SEND-Funktion zu setzen und entsprechend in der RECEIVE-Funktion abzufragen. Bei der Beschreibung der Communication Layer in RFC 1122 wurde dies jedoch als optional definiert. Tatsächlich sehen die aktuellen Sockets-Implementierungen, die Unix BSD Sockets und Winsock, das PUSH-Flag weder in der SEND- noch in der RECEIVE-Funktion vor. Daher wird gemäß RFC 1122 das PSH-Flag im letzten gepufferten TCP-Segment (IP-Paket) jedes Aufrufs automatisch gesetzt. Dadurch kann durch Prüfen der TCP-Header festgestellt werden, ob in mehreren Segmenten empfangene Daten in einem einzelnen Aufruf (= Das PSH-Bit ist nur im letzten Segment gesetzt) oder mehreren Aufrufen (= Das PSH-Bit ist in jedem Segment gesetzt) gesendet wurden. Dies kann man zur Erkennung von Angriffen ausnutzen, wenn zwei Anforderungen erfüllt sind.

Anforderungen zum Erkennen von HTTP Response Splitting (mehr dazu in der nächsten Folge):

• Kein 'Pipelining': Eine zweite HTTP-Response darf erst akzeptiert werden, wenn die erste vollständig verarbeitet und ein zweiter HTTP-Request vollständig empfangen wurde. Praktisch bedeutet dies, dass ein Paket mit Daten der ersten Response keine weiteren, überflüssigen Daten enthalten darf.
• Aus der ersten Anforderung folgt, dass das Ende der ersten Response mit dem Ende eines Pakets und einer Übertragung übereinstimmen muss. Daher muss das entsprechende Paket ein gesetztes PSH-Bit enthalten.

Um HTTP Request Smuggling zu erkennen, muss der Webserver die vom Proxy-Server empfangenen Requests daraufhin prüfen, ob ihr Ende mit dem eines Pakets übereinstimmt und ob in diesem Paket das PSH-Bit gesetzt ist. Wird ein Angriff erkannt, kann die TCP-Verbindung beendet und damit der Angriff abgewehrt werden.

Das Verfahren schlägt fehl, wenn Systeme zwischen Web- und Cache-Server den TCP-Stream verändern oder ein beteiligtes System in jedem Paket das PSH-Bit setzt. Dies trifft z.B. auf den TCP-Stack von IBMs TPF 4.1 in der Default-Konfiguration zu.

HTTP Request Smuggling verhindern

Um HTTP Request Smuggling vollständig unmöglich zu machen, müssten alle HTTP nutzenden Geräte den HTTP-Standard gleich umsetzen. Da dazu alle unterschiedlichen Interpretationen auf einen Nenner gebracht werden müssten, ist mit dieser Lösung vorerst nicht zu rechnen. Also müssen andere Gegenmaßnahmen ergriffen werden.

Das oben beschriebene Verfahren ist gut zum Einsatz in Intrusion-Detection- oder -Prevention-Systemen geeignet. Es muss lediglich der TCP/IP-Verkehr belauscht und jeder HTTP-Request und jede HTTP-Response, die nicht an einer Paketgrenze mit gesetzten PSH-Bit im Paket enden, aussortiert werden.

Befinden sich Cache- und Webserver am gleichen Ort, kann eine Kombination gewählt werden, die nicht für HTTP Request Smuggling anfällig ist. Dies schützt natürlich nicht davor, dass ein vorgelagerter Cache-Server angegriffen bzw. für einen Angriff ausgenutzt wird. Eine Firewall vor dem Cache- und/oder Webserver kann vor einem Teil der Angriffe schützen, ist selbst jedoch in manchen Fällen ebenfalls angreifbar. Außerdem kann die Firewall natürlich nur vor Angriffen auf hinter ihr liegende Server schützen.

Die Verwendung eines Webservers, der die HTTP-Requests sehr strikt parst, kann ebenfalls vor Angriffen schützen. Der Apache war z.B. nur in einem – inzwischen behobenen – Fall für HTTP Request Smuggling anfällig, wenn er sowohl als Web- als auch als Cache-Server eingesetzt wurde.

Dass bekannte Schwachstellen behoben und die entsprechenden Patches bzw. Updates installiert werden müssen, sollte selbstverständlich sein. Die von Watchfire gefundenen Schwachstellen (PDF) in Squid, der Checkpoint Firewall FW-1 und dem Apache-Webserver wurden inzwischen behoben. Allerdings bleiben noch genug verwundbare Kombinationen übrig, die auch noch nicht alle untersucht wurden.

Damit ist die Beschreibung der durch HTTP Request Smuggling möglichen Angriffe und ihrer Abwehr abgeschlossen. In der nächsten Folge geht es um das damit verwandte HTTP Response Splitting.

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