imported>Matthäus Wander: HC: Ergänze Kategorie:HTTP

2023-07-24T14:41:51Z

Neue Seite

'''HTTP Response Splitting''' (dt.: Aufteilung der [[Hypertext Transfer Protocol|HTTP]]-Antwort) ist eine [[Sicherheitslücke]], die zur Durchführung von [[Cross-Site-Scripting]]-Attacken, (Cross-User-)[[Defacement]]s, ''Web cache poisoning'' und ähnlichen [[Exploit]]s verwendet werden kann.

== Funktionsweise ==
Um die Attacke durchzuführen, werden mehrere [[Zeilenvorschub|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 zerteilen. Wird für weitere Anfragen die gleiche TCP-Verbindung genutzt ([[HTTP-Pipelining]]), 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 als <code>„\r\n“</code> darstellbar) das gültige Ende einer Header-Zeile. Allerdings akzeptieren viele [[User Agent]]s 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 „Web 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 [[Proxyserver|Webproxy]] einfließen zu lassen.

== Beispiel ==
Angenommen sei eine Seite, deren Code ungeprüft eine GET-Variable in die Header übernimmt. Hier in [[PHP]]:
header("Location: ".$_GET["seite"]."\r\n");
Eine gutartige Anfrage könnte den Parameter <code>seite</code> z. B. auf <nowiki>http://de.wikipedia.org</nowiki> setzen. Die HTTP-Antwort könnte dann so aussehen:
<syntaxhighlight lang="text" style="border: none">
HTTP/1.1 301 Moved Permanently
Location: http://de.wikipedia.org/
</syntaxhighlight>
Eine bösartige Seite allerdings könnte einen kompliziert aussehenden String wie den folgenden senden: <code>%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</code>

„Übersetzt“ man die URL-Kodierungen und injiziert diese wie oben in die Antwort, so erhält man
<syntaxhighlight lang="text">
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>
</syntaxhighlight>
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.

[[Kategorie:Sicherheitslücke|Http Response Splitting]]
[[Kategorie:HTTP]]

HTTP Response Splitting - Versionsgeschichte

imported>Matthäus Wander: HC: Ergänze Kategorie:HTTP