Mittwoch, 22. August 2012


Topthema

Donnerstag, 22. September 2005 | Topthema

About Security #24: Caches indirekt vergiften

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/024285)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

�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.

About Security: Die komplette Serie

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:

  1. Zuerst wird eine gegebenenfalls im Cache vorhandene Version der Seite ung�ltig gemacht (Zeile 3 bis 5).
  2. Danach wird der HTTP-Response-Splitting-Angriff gestartet (Zeile 7 und 8).
  3. 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!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren