HTTP-Response Splitting

0 | 2 Kommentare | 1936 Aufrufe
Sie können diese Wikiseite nach der Anmeldung auf Webmasterpro bearbeiten. Helfen Sie mit und verbessern Sie "HTTP-Response Splitting" mit Ihrem Wissen!

Anzeige Hier werben

Verwandte Angriffe:

Kurze Beschreibung:

HTTP-Response Splitting tritt auf, wenn:

  • Daten durch eine nicht vertrauenswürdige Quelle auf eine Webapplikation geschrieben werden, meistens eine HTTP-Anfrage
  • Die Daten in einem HTTP-Response-Header geschickt werden, ohne das vorher die Zeichen maskiert werden

Um einen Angriff erfolgreich zu gestalten, muss die Applikation Eingaben zulassen, die CR (carriage return, %0d oder \r) und LF (line feed, %0a oder \n) beinhalten. Diese Zeichen geben dem Angreifer nicht nur die Kontrolle über den übrigen Header und Body, sondern ermöglichen das Erstellen von weiteren Responses, die komplett in ihrer Kontrolle liegen

Folgen:

HTTP Response Splitting 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 eine HTTP-Response Splitting 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 Benutzereingaben nicht oder unzureichend prüft 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 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 aus carriage return und linefeed das gültige Ende einer Header-Zeile. Allerdings akzeptieren viele User Agents auch ein einzelnes Auftreten von CR oder LF als Zeilenende. Beim Nutzer besteht die zweite Antwort aus dem vom Angreifer injizierten Daten. Setzt dieser nun gezielt HTML oder JavaScript ein, so kommt es zur schlichten Verunstaltung oder sogar schwerwiegenden Cross-Site Scripting Angriffen.

Beispiel:

Angenommen eine Seite würde ungeprüft eine GET-Variable in den Header übernehmen.

 
PHP
1
header("Location: ".$_GET["seite"]."\r\n");

Eine gutartige Anfrage könnte den Parameter seite z.B. auf http://www.webmasterpro.de/ setzen. Die HTTP-Antwort könnte dann so aussehen:

 
Text
1
2
HTTP/1.1 301 Moved Permanently
Location: http://www.webmasterpro.de/

Sendet eine Anfrage allerdings einen solch komplizierten String wie diesen hier:

%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

hat man es mit einer bösartigen Anfrage zu tun. Die HTTP-Antwort würde in diesem Fall so aussehen:

 
Text
1
2
3
4
5
6
7
8
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.

Gegenmaßnahmen:

Abhilfe schafft das gründliche Überprüfen aller Eingabeparameter bevor diese in einen Header geschrieben werden. Dies kann auch von einer Bibliotheksfunktion übernommen werden.

Fazit:

HTTP-Response Splitting manipuliert die HTTP-Antwort und kann zu gefährlichen Cross-Site Scripting Attacken genutzt werden. Damit kann der Response komplett übernommen werden. Die Attacke ist deshalb sehr gefährlich und muss ernst genommen werden.

zurück zur Übersicht Web-Sicherheit

Wikiseite bearbeiten

Diese Seite kann von jedem registrierten Benutzer bearbeitet werden. Bisher haben 2 Personen an der Seite "HTTP-Response Splitting" mitgewirkt.

Sie haben einen Fehler entdeckt oder möchten etwas ergänzen? Dann können Sie nach der Anmeldung "HTTP-Response Splitting" hier bearbeiten.

Mitarbeiter

Kommentare: HTTP-Response Splitting

Neuen Kommentar schreiben
Beispiel Gegenmaßnahme
Beantworten

Wie könnte / würde denn die Gegenmaßnahme (Überprüfung der GET-Variable) zu dem Beispiel im Artikel aussehen?

Sebastian ! am 30.11.2010 um 09:13
Re: Beispiel Gegenmaßnahme
Beantworten

Eine Möglichkeit wäre, Header nirgends mehr im Script direkt auszugeben, sondern sich dafür eine Sammelstelle zu bauen – also eine eigene Klasse – und vor dem Seiten-Shutdown parsen.

Ich behelfe mir aktuell damit:

if(preg_match("#\r\n#", urldecode($value)) || preg_match("#\r#", urldecode($value)) || preg_match("#\n#", urldecode($value)) || preg_match("#\r\n#", $value) || preg_match("#\r#", $value) || preg_match("#\n#", $value) ) Toolkit::stop (__LINE__, __CLASS__, 'Splitter detected.');

Ich kann allerdings nicht sagen, ob man das nicht auch irgendwie aushebeln kann.

Denn GET wäre nur eine Quelle. Verseuchte Cookies oder Request-Header, sowie POST und FILE (kann man sicher auch lustiges mit Dateinamen machen) wären im Grunde auch eine.

Schade, dass der Autor nur den Wikipedia-Artikel übernommen hat und keinen praktischen Lösungsansatz vermittelt.

Carsten Braun am 15.12.2010 um 07:04