- HTTP Response Splitting
-
HTTP Response Splitting (dt.: Aufteilung der HTTP-Antwort) ist eine Sicherheitslücke, welche zur Durchführung von Cross-Site Scripting-Attacken, (Cross-User) Defacements, Web cache poisoning und ähnlichen Exploits verwendet werden kann.
Funktionsweise
Um die Attacke durchzuführen, werden mehrere Zeilenvorschübe gefolgt von den Daten des Angreifers per Header-Injection in den Header einer HTTP-Antwort eingefügt. Im HTTP-Standard signalisiert die erste Leerzeile das Ende des Header-Bereichs und damit in der Regel den Beginn der Nutzdaten. Wenn die Webanwendung es versäumt, Benutzereingaben zu prüfen und damit Zeilenvorschübe in einem Header erlaubt, dann kann ein möglicher Angreifer die Kontrolle über die Nutzlast übernehmen und die HTTP-Antwort in zwei Teile zu zerteilen. Wird für weitere Anfragen die gleiche TCP-Verbindung genutzt, dann erscheint der zweite Teil der geteilten Antwort als Antwort auf die nächste Anfrage.
Gemäß dem Standard ist nur die Kombination "CR LF" (carriage return + linefeed, in vielen Programmiersprachen auch bekannt durch
"\r\n"darstellbar) das gültige Ende einer Header-Zeile. Allerdings akzeptieren viele User Agents auch ein einzelnes Auftreten von CR oder LF als Zeilenende.Beim Benutzer besteht die zweite Antwort also aus den vom Angreifer injizierten Daten. Setzt dieser nun gezielt HTML oder JavaScript ein, so kommt es zur schlichten Verunstaltung (Defacement) oder sogar schwerwiegenden Cross-Site-Scripting-Angriffen.
Beim "Cache Poisoning" (dt.: Cache-Vergiftung) wird der Header so modifiziert, dass Cache-relevante Header-Felder verändert werden, um die veränderte Seite in den Cache eines Webproxy einfließen zu lassen.
Beispiel
Angenommen sei eine Seite, deren Pseudocode ungeprüft eine GET-Variable in die Header übernimmt.
header("Location: ".$_GET["seite"]."\r\n");Eine gutartige Anfrage könnte den Parameter
seitez.B. auf http://de.wikipedia.org setzen. Die HTTP-Antwort könnte dann so aussehen:HTTP/1.1 301 Moved Permanently Location: http://de.wikipedia.org
Eine bösartige allerdings könnte einen kompliziert aussehenden String wie den folgenden senden.
%0d%0a%0a%3Chtml%3E%3Cbody%3Eerste Antwort%3C/body%3E%3C/html%3E%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cbody%3Ezweite Antwort%3C/body%3E%3C/html%3E"Übersetzt" man die URL-Kodierungen und injiziert diese wie oben in die Antwort so erhält man
HTTP/1.1 301 Moved Permanently Location: <html><body>erste Antwort</body></html> HTTP/1.1 200 OK Content-Type: text/html <html><body>zweite Antwort</body></html>
Es wurde also die eigentliche Antwort um eine zweite ergänzt. Diese Antwort würde jetzt bei der nächsten Anfrage über die gleiche HTTP-Verbindung an den Browser oder Proxy gesendet werden obwohl dieser eigentlich eine andere Anfrage gestellt hat.
Abhilfe
Abhilfe schafft das gründliche Überprüfen aller Eingabeparameter bevor diese in einen Header geschrieben werden. Dies kann auch von einer Bibliotheksfunktion übernommen werden.
Wikimedia Foundation.
