CWE-113: Failure to Sanitize CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Individual Definition in a New Window
Failure to Sanitize CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Status: Incomplete
Weakness ID: 113 (Weakness Base)
Description
Summary
The software fails to adequately filter HTTP headers for CR and
LF characters.
Extended Description
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 and LF 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.
1. Data enters a web application through an untrusted source, most
frequently an HTTP request.
2. The data is included in an HTTP response header sent to a web user
without being validated for malicious characters.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Demonstrative Examples
Example 1:
The following code segment reads the name of the author of a weblog
entry, author, from an HTTP request and sets it in a cookie header of an
HTTP response.
Assuming a string consisting of standard alpha-numeric characters,
such as "Jane Smith", is submitted in the request the HTTP response
including this cookie might take the following form:
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
However, because the value of the cookie is formed of unvalidated user
input the response will only maintain this form if the value submitted
for AUTHOR_PARAM does not contain any CR and LF characters. If an
attacker submits a malicious string, such as
Wiley Hacker\r\nHTTP/1.1 200 OK\r\n
then the HTTP response would be split into two responses of the
following form:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker HTTP/1.1 200 OK
...
Clearly, the second response is completely controlled by the attacker
and can be constructed with any header and body content desired. The
ability of attacker to construct arbitrary HTTP responses permits a
variety of resulting attacks, including:
cross-user defacement
web and browser cache poisoning
cross-site scripting
page hijacking
Example 2:
An attacker can make a single request to a vulnerable server that
will cause the sever to create two responses, the second of which
may be misinterpreted as a response to a different request, possibly
one made by another user sharing the same TCP connection with the
sever. This can be accomplished by convincing the user to submit the
malicious request themselves, or remotely in situations where the
attacker and the user share a common TCP connection to the server,
such as a shared proxy server.
In the best case, an attacker can leverage this ability to
convince users that the application has been hacked, causing
users to lose confidence in the security of the
application.
In the worst case, an attacker may provide specially crafted
content designed to mimic the behavior of the application but
redirect private information, such as account numbers and
passwords, back to the attacker.
Example 3:
The impact of a maliciously constructed response can be magnified
if it is cached either by a web cache used by multiple users or even
the browser cache of a single user. If a response is cached in a
shared web cache, such as those commonly found in proxy servers,
then all users of that cache will continue receive the malicious
content until the cache entry is purged. Similarly, if the response
is cached in the browser of an individual user, then that user will
continue to receive the malicious content until the cache entry is
purged, although the user of the local browser instance will be
affected.
Example 4:
Once attackers have control of the responses sent by an
application, they have a choice of a variety of malicious content to
provide users. Cross-site scripting is common form of attack where
malicious JavaScript or other code included in a response is
executed in the user's browser.
The variety of attacks based on XSS is almost limitless, but they
commonly include transmitting private data like cookies or other
session information to the attacker, redirecting the victim to web
content controlled by the attacker, or performing other malicious
operations on the user's machine under the guise of the vulnerable
site.
The most common and dangerous attack vector against users of a
vulnerable application uses JavaScript to transmit session and
authentication information back to the attacker who can then take
complete control of the victim's account.
Example 5:
In addition to using a vulnerable application to send malicious
content to a user, the same root vulnerability can also be leveraged
to redirect sensitive content generated by the server and intended
for the user to the attacker instead. By submitting a request that
results in two responses, the intended response from the server and
the response generated by the attacker, an attacker can cause an
intermediate node, such as a shared proxy server, to misdirect a
response generated by the server for the user to the
attacker.
Because the request made by the attacker generates two responses,
the first is interpreted as a response to the attacker's request,
while the second remains in limbo. When the user makes a legitimate
request through the same TCP connection, the attacker's request is
already waiting and is interpreted as a response to the victim's
request. The attacker then sends a second request to the server, to
which the proxy server responds with the server generated request
intended for the victim, thereby compromising any sensitive
information in the headers or body of the response intended for the
victim.
Bulletin board allows response splitting via CRLF
in parameter.
Potential Mitigations
Construct HTTP headers very carefully, avoiding the use of
non-validated input data.
Assume all input is malicious. Use a standard input validation
mechanism to validate all input for length, type, syntax, and business
rules before accepting the data to be diplayed or stored. Use an "accept
known good" validation strategy. Input (specifically, unexpected CRLFs)
that is not appropriate should not be processed into HTTP
headers.
Use and specify a strong output encoding (such as ISO 8859-1 or UTF
8).
Do not rely exclusively on blacklist validation to detect malicious
input or to encode output. There are too many variants to encode a
character; you're likely to miss some variants.
Inputs should be decoded and canonicalized to the application's
current internal representation before being validated. Make sure that
your application does not decode the same input twice. Such errors could
be used to bypass whitelist schemes by introducing dangerous inputs
after they have been checked.
Other Notes
As with many software security vulnerabilities, HTTP response splitting is
a means to an end, not an end in itself. At its root, the vulnerability is
straightforward: an attacker passes malicious data to a vulnerable
application, and the application includes the data in an HTTP response
header. To mount a successful exploit, the application must allow input that
contains CR (carriage return, also given by %0d or \r) and LF (line feed,
also given by %0a or \n)characters into the header. These characters not
only give attackers control of the remaining headers and body of the
response the application intends to send, but also allows them to create
additional responses entirely under their control.
Note that HTTP response splitting is probably only multi-factor in an
environment that uses intermediaries.
Description
Implementation
