HTTP Response Splitting

HTTP Response Splitting (German: Distribution of HTTP response ) is a security gap which web cache poisoning and similar exploits can be used to perform cross-site scripting attacks (cross -user ) defacements.

Operation

To perform the attack, several line feeds followed by the data to be inserted by the attacker header injection into the header of an HTTP response. In the HTTP standard, the first blank line signals the end of the header area, and thus usually the beginning of the payload. If the Web application fails to validate user input and thus allows newlines in a header, then a potential attacker to take control of the payload and divide the HTTP response into two parts., The same TCP connection is used for further requests will appear, the second part of the divided response in response to the next request.

According to the standard is only the combination of "CR LF " (carriage return line feed, in many programming languages ​​as "\ r \ n" represented ) the valid end of a header row. However, many user agents also accept a single occurrence of CR or LF as end of line.

When the second user response thus consists of the injected by the attacker data. Sets this now targeting an HTML or JavaScript, so it comes to simple defacement ( defacement ) or even serious cross-site scripting attacks.

In the " Web Cache Poisoning " (Eng.: cache poisoning), the header is modified so that cache -related header fields are modified to incorporate the changed page in the cache for a Web proxy.

Example

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

" Translated " to the URL encodings and injected as described above in this response, we obtain

HTTP/1.1 301 Moved Permanently   Location:   first response     HTTP/1.1 200 OK   Content-Type: text / html     second answer The real answer It was supplemented by a second. This response would now be sent in the next request on the same HTTP connection to the browser or proxy, although this has actually made ​​another request.

Remedy

Remedy the thorough check of all input parameters before they are written to a header. This can also be acquired by a library function.

  • Vulnerability
401368
de