Demonstrative Examples | 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. String author = request.getParameter(AUTHOR_PARAM); ... Cookie cookie = new Cookie("author", author); cookie.setMaxAge(cookieExpiration); response.addCookie(cookie); 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 and page hijacking. Others examples:
Cross-User Defacement: 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. Cache Poisoning: 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. Cross-Site Scripting: 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. Page Hijacking: 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. |
| Context Notes | HTTP response splitting vulnerabilities occur when: 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. 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. |