Übre HTTP-Response-Splitting-Angriffe sind auch Cross-Site Scripting und das Vergiften nicht direkt zugänglicher Caches möglich. Wie das funktioniert, verrät diese Folge von About Security.
Cross-Site Scripting mit Internet Explorer 6.0 SP1
N E U ! Security
aktuell
Täglich aktuelle Security-Infos!
Im Vergleich zum Vergiften des Browser-Caches (siehe About Security #23) ist die Situation beim Cross-Site Scripting einfacher, da es egal ist, welcher HTTP-Request der zweiten HTTP-Response zugeordnet wird. Jeder weitere HTTP-Request über dieselbe TCP-Verbindung ist für dieselbe Website. Der Angriff ist daher erfolgreich, sofern der Server die TCP-Verbindung nicht beendet. Beendet der Server die Verbindung bei der Redirection, kann eine Bombardierung mit HTTP-Requests nach dem Muster aus About Security #23 zum Erfolg führen (Bsp. nach Amit Klein, "Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics", PDF):
<frameset cols="5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,
5%,5%,5%">
<frame src="http://www.opfer.example/redir_lang.jsp?lang=%0d%0aConne
ction:%20Keep-Alive%0d%0a%0d%0aAAAAAAAA ... [Auffüllen auf 1024 Bytes]...
AAAAAAAAAAAAAAHTTP/1.1%20200%20OK%0d%0aContentType:%20text/html%0
d%0aLastModified:%20Sat,%2003%20Dec%202005%2001:23:45%20GMT%0d%0a
ContentLength:%2052%0d%0a%0d%0a<html><script>alert(document.cooki
e)</ script></html>
">
<frame src="http://www.opfer.example/index.html"> ... [19 weitere dieser <frame>s] ... </frameset>
Im Gegensatz zum Vergiften des Browser-Caches ist es nicht notwendig, zwei HTTP-Requests abwechselnd zu senden. Der Cross-Site-Scripting-Angriff ist auch erfolgreich, wenn die eingeschleuste zweite HTTP-Response einem weiteren HTTP Response Splitting Request zugeordnet wird.
Indirektes Vergiften von Cache-/Proxy-Servern
Das Vergiften des Browser-Caches unterscheidet sich von Angriffen auf andere Ziele in dem Punkt, dass der Angreifer den HTTP Response Splitting Request nicht selbst sendet, sondern von einem Dritten (in diesem Fall dem Benutzer des Browsers) senden lässt. So ist ihm ein Angriff auf ein Ziel möglich, auf das er selbst nicht zugreifen kann.
Verbunden mit einem Cross-Site-Scripting-Angriff kann dieses Verfahren auch zum Angriff auf andere, nicht direkt zugängliche Ziele ausgenutzt werden. Ein derartiges Ziel sind zum Beispiel Proxy-Server innerhalb eines lokalen Netzes. Um deren Cache zu vergiften, kann über Cross-Site Scripting JavaScript-Code in einem Webbrowser im lokalen Netz eingeschleust werden, der dann einen HTTP-Response-Splitting-Angriff zum Vergiften des Caches des internen Servers startet. Zum Erzeugen der nötigen HTTP-Header kann beispielsweise ein XMLHttpRequest verwendet werden.
Durchführung des Angriffs
Der Angreifer lässt einen Benutzer eine Webseite öffnen, die beim Aufruf einen Cross-Site-Scripting-Angriff auslöst. Darüber wird JavaScript-Code in den Webbrowser des Benutzers eingeschleust, der einen HTTP-Response-Splitting-Angriff zum Vergiften des Proxy-Server-Caches startet.
Folgendes Beispiel (nach dem oben genannten Whitepaper) für den entsprechenden JavaScript-Code geht zur Vereinfachung von einigen Annahmen aus:
- Ziel ist ein Apache-2.0-Forward-Proxy-Server
- Als Browser wird der Internet Explorer 6.0 SP1 verwendet
- Das verwundbare Skript auf dem Webserver setzt einen Cookie unter Verwendung vom Benutzer gelieferter Daten. Im Fall einer Redirection müsste die Race Condition des Internet Explorers berücksichtigt werden.
- Der Browser verwendet HTTP/1.1 zur Kommunikation mit dem Proxy-Server. Andernfalls beendet der XMLHttpRequest die TCP-Verbindung nach jedem HTTP-Request.
1 var r = new ActiveXObject("Microsoft.XMLHTTP");
2 3 r.open("GET","http://www.opfer.example/index.html",false);
4 r.setRequestHeader("Pragma","no-cache");
5 r.send();
6 7 r.open("GET","http://www.opfer.example/SetLang.aspx?lang=%0d%0a
ContentLength:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLastMo
dified:%20Sat,%2003%20Dec%202005%2001:23:45%20GMT%0d%0aConten
t-Length:%2023%0d%0aContentType:%20text/html%0d%0a%0d%0a<html
>Geschafft!</html>",false);
8 r.send();
9 10 r.open("GET","http://www.opfer.example/index.html",false);
11 r.send();
Das Skript geht wie in About Security #23 beschrieben vor:
- Zuerst wird eine gegebenenfalls im Cache vorhandene Version der Seite ungültig gemacht (Zeile 3 bis 5).
- Danach wird der HTTP-Response-Splitting-Angriff gestartet (Zeile 7 und 8).
- Zuletzt wird die Seite aufgerufen, die vergiftet werden soll (Zeile 10 und 11).
Jede für HTTP Response Splitting anfällige Seite ist auch für Cross-Site Scripting anfällig. Daher können auf diese Weise Caches vergiftet werden, auf die der Angreifer nicht direkt zugreifen kann.
In der nächsten Folge wird das Thema HTTP Response Splitting mit einem letzten Beispiel für einen Angriff abgeschlossen: Das Entführen von Webseiten mit sensitiven Informationen. Außerdem erfahren Sie, wie Sie HTTP-Response-Splitting-Angriffe erkennen und verhindern können.
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 – Ü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
Kommentare