HTTP response splitting

from Wikipedia, the free encyclopedia

HTTP response splitting (dt .: Distribution of HTTP response) is a security issue , which to conduct cross-site scripting attacks, (cross-user) defacements , web cache poisoning and similar exploits can be used.

functionality

In order to carry out the attack, multiple line feeds followed by the attacker's data are inserted into the header of an HTTP response via header injection . In the HTTP standard, the first blank line signals the end of the header area and thus usually the beginning of the user data. If the web application fails to check user input and thus allows line feeds in a header, a possible attacker can take control of the payload and split the HTTP response into two parts. If the same TCP connection is used for further requests ( HTTP pipelining ), then the second part of the split response appears as the response to the next request.

According to the standard, only the combination “CR LF” ( carriage return + linefeed , can be represented in many programming languages „\r\n“) is the valid end of a header line. However, many user agents also accept a single occurrence of CR or LF as the end of a line.

For the user, the second response consists of the data injected by the attacker. If it uses HTML or JavaScript in a targeted manner , simple defacement or even serious cross-site scripting attacks occur.

With "web cache poisoning" (dt .: cache poisoning) the header is modified in such a way that cache-relevant header fields are changed in order to allow the changed page to flow into the cache of a web proxy .

example

Let us assume a page whose code accepts a GET variable in the header without being checked. Here in PHP : 

header("Location: ".$_GET["seite"]."\r\n");

A benign query could include the parameter seitee.g. B. set to http://de.wikipedia.org. The HTTP response could then look like this: 

 HTTP/1.1 301 Moved Permanently
 Location: http://de.wikipedia.org/

However, a malicious site could send a complex looking string like this: %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

If you “translate” the URL encodings and inject them into the answer as above, you get 

 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>

So a second answer was added to the actual answer. This response would now be sent to the browser or proxy with the next request over the same HTTP connection, even though the latter actually made a different request.

remedy

This can be remedied by thoroughly checking all input parameters before they are written to a header. This can also be done by a library function.