Unfiltered Header Injection in Apache 1.3.34/2.0.57/2.2.1, CWE-113 PoC, Expect RXSS

HTTP Header Injection Reports | HTTPi - Set Cookie PoC | HTTPi - Location Response PoC | HTTPi - Eyeblaster Cookie PoC
Loading
XSS in texasgroup.net, DORK, Cross Site Scripting, CWE-79, CAPEC-86

CWE-113: HTTP header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way.

If an attacker can inject newline characters into the header, then they can inject new HTTP headers and also, by injecting an empty line, break out of the headers into the message body and write arbitrary content into the application's response.

Various kinds of attack can be delivered via HTTP header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via header injection, because the attacker can construct a request which causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request which results in a "split" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a "stored" attack against this URL which will compromise other users who request that URL in future.

Including unvalidated data in an HTTP header allows an attacker to specify the entirety of the HTTP response rendered by the browser. When an HTTP request contains unexpected CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n) characters the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks.

A HTTP Header Injection Vulnerability means an Attacker can inject malicious input that goes into HTTP headers without proper input filtering. The Application Response contained a CRLF (New line) injection in the HTTP headers.
Depending on the application. An attacker might carry out the following forms of attacks:
  • Cross-site Scripting attack which can lead to session hijacking
  • Session fixation attack by setting a new cookie, which can again lead to session hijacking

Actions to Take

  1. See the remedy for solution.
  2. Ensure the server security patches are up to date and that the current stable version of the software is in use.

Remedy

Do not allow newline characters in input. Where possible use strict white listing. If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.

Required Skills for Successful Exploitation

Crafting the attack to exploit this issue is not a complex process. However most of the unsophisticated attackers will not know that such an attack is possible. Also an attacker needs to reach his victim by an e-mail or other similar method in order to entice them to visit the site or click upon a URL.

External References