Diese Woche geht es um Schwierigkeiten beim HTTP Response Splitting. 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 die 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 eine URL für einen GET-Requests 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 aus der letzten Woche
aussieht. Der Erfolg hängt davon ab, wie die Antwort interpretiert und
Ende bzw. Anfang einer HTTP-Response erkannt wird. In folgenden drei
Fällen konnten HTTP-Response-Splitting-Angriffe erfolgreich
durchgeführt werden [1, PDF]:
- Erkennung an Nachrichtengrenzen: Die zweite Nachricht beginnt direkt nach dem Ende der ersten. In diesem Fall funktioniert der Angriff aus dem Beispiel der letzten Woche.
- 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
sicher stellen, 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.
Soviel zu den Schwierigkeiten des HTTP Response Splitting. Nächste Woche geht es um die praktische Durchführung.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen.
- About Security (#1): IT-Sicherheit – Was ist das eigentlich?
- About Security (#2): Angriffsszenarien
- About Security (#3): Eindringlinge abwehren
- About Security (#4): Gefährdung aus der Peripherie
- About Security (#5): Der Pufferüberlauf
- About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
- About Security (#7): Gegenwehr – Pufferüberläufe verhindern
- About Security (#8): Vorbeugung – Pufferüberläufe verhindern
- About Security (#9): Sourcecode Audit – Pufferüberläufe finden
- About Security (#10): Software-Audit – Schwachstellensuche in Binaries
- 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
