Channel Security

Als letzter Angriff über HTTP Response Splitting wird in dieser Folge das Entführen von Webseiten mit sensitiven Informationen beschrieben. Außerdem erfahren Sie, wie HTTP Response Splitting erkannt und verhindert werden kann.

Entführen sensitiver Informationen

Wenn zwei Benutzer die gleiche Verbindung nutzen, kann der eine Benutzer über einen HTTP-Response-Splitting-Angriff eine für den anderen Benutzer bestimmte HTTP Response zu sich umleiten.

Das folgende Beispiel (nach Amit Klein, "Divide and Conquer – HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics", PDF) geht von einem Angreifer, einem angegriffenen Benutzer, einem verwundbaren Webserver und einem zwischengeschalteten Proxy-Server aus. Der Proxy-Server teilt Verbindungen auf mehrere Benutzer auf.

Die TCP-Verbindung zwischen Angreifer und Proxy-Server wird mit AP bezeichnet, die zwischen Opfer und Proxyserver mit OP. Die TCP-Verbindung zwischen Proxy- und Webserver heißt PW. Der Angriff läuft dann nach folgendem Schema ab:

1. Der Angreifer sendet über AP einen HTTP Response Splitting Request A an den Proxy-Server.
2. Der Proxy-Server leitet A über PW an den Webserver weiter.
3. Der Webserver erzeugt die HTTP-Responses a1 und a2, die er über PW an den Proxy-Server sendet.
4. Der Proxy-Server interpretiert a1 als Antwort auf A und leitet sie über AP an den Angreifer weiter.
5. Das Opfer sendet über OP seinen HTTP-Request B an den Proxy-Server.
6. Der Proxy-Server leitet B über PW an den Webserver weiter und interpretiert a2 als Antwort darauf.
7. Der Proxy-Server sendet a2 als Antwort auf den HTTP-Request B über OP an das Opfer.
8. Der Angreifer sendet über AP einen beliebigen HTTP-Request C an den Proxy-Server.
9. Der Proxy-Server empfängt vom Webserver über PW die HTTP-Response b als Antwort auf den HTTP-Request B.
10. Der Proxy-Server leitet C über PW an den Webserver weiter und interpretiert b als Antwort darauf.
11. Der Proxy-Server sendet b als Antwort auf den HTTP-Request C über AP an den Angreifer. Damit erhält der Angreifer die Antwort auf die Anfrage des Opfers, die sensitive Informationen enthalten kann.
12. Der Proxy-Server empfängt vom Webserver über PW die HTTP-Response c als Antwort auf den HTTP-Request C. Da diese HTTP-Response keinem HTTP-Request zugeordnet werden kann, wird sie nach einiger Zeit, spätestens beim Schließen der TCP-Verbindung, verworfen.

Da das Timing für einen erfolgreichen Angriff sehr genau abgestimmt sein muss, ist ein derartiger Angriff schwierig durchzuführen.

Angriffe erkennen

Nachträglich einen Angriff zu erkennen, ist nur im Fall von GET-Requests möglich: Ein entsprechend präparierter Parameter wird in den Logdateien protokolliert. Erfolgt der Angriff über einen POST-Request, werden die Parameter nicht protokolliert. Da die eingeschleusten Daten normalerweise direkt in den HTTP-Ausgabestrom integriert werden, fallen auch keine geänderten Dateien o.Ä. auf. Und wurde zum Beispiel ein Cache vergiftet, kann eine Schutzfunktion auf dem Webserver dies nicht erkennen, da die Daten auf dem Webserver selbst unverändert sind. Ein derartiger Angriff lässt sich eventuell nachweisen, wenn außer den Logdateien des Webservers auch die des beteiligten Cache-Servers zur Verfügung stehen und der genaue Zeitpunkt des Angriffs bekannt ist. War der Angreifer nachlässig, befindet sich die vergiftete Seite eventuell noch im Cache. In den meisten Fällen wird der Angreifer sie jedoch wieder aus dem Cache entfernen, nachdem er sein Ziel erreicht hat.

Um laufende HTTP-Response-Splitting-Angriffe zu erkennen, kann das in About Security #20 beschriebene Verfahren verwendet werden, das das PSH-Bit nutzt. Es ist gut zum Einsatz in Intrusion-Detection- oder -Prevention-Systemen geeignet. Erkannte Angriffe können dann durch Verwerfen der entsprechenden Pakete beendet werden.

Angriffe verhindern

Um HTTP-Response-Splitting-Angriffe zu verhindern, gibt es für die verschiedenen Beteiligten unterschiedliche Möglichkeiten:

• Webanwendungen müssen gefährliche Zeichen, insbesondere CR und LF (%0d, %0a) ausfiltern, bevor sie Daten in eine HTTP-Response einfügen.
• Für Webanwendungen verwendete APIs, Bibliotheken etc. müssen ebenfalls CR, LF und andere gefährliche Zeichen aus HTTP-Response-Headern filtern. Der HTTP-Standard RFC 2616 definiert CRLF als Kennzeichnung für das Zeilenende, sodass diese Zeichenfolge nicht Bestandteil von Header-Werten sein darf.
• Proxy-Server sollten keine TCP-Verbindungen auf verschiedene Benutzer oder Server aufteilen.
• Clients (sowohl Webbrowser als auch Cache-/Proxy-Server) sollten ebenfalls keine TCP-Verbindungen zwischen verschiedenen Servern aufteilen. Werden HTTP-Requests über einen Forward Proxy gesendet, sollten für verschiedene Server jeweils separate TCP-Verbindungen verwendet werden.

Damit ist das Thema "HTTP Response Splitting" abgeschlossen. In der nächsten Folge lernen Sie einige weitere Schwachstellen in Webanwendungen kennen.

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