273
HTTP Response Splitting :
Common Consequences
Scope Impact Likelihood
Integrity
Access Control
Modify Application Data
Gain Privileges or Assume Identity
CR and LF characters in an HTTP header may give
attackers control of the remaining headers and body of
the message that the application intends to send/receive,
as well as allowing them to create additional messages
entirely under their control.
Detection Methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST),
can find some instances of this weakness by analyzing source code (or binary/compiled code)
without having to execute it. Typically, this is done by building a model of data flow and control
flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input)
with "sinks" (destinations where the data interacts with external components, a lower layer such
as the OS, etc.)
Effectiveness = High
Potential Mitigations
Phase: Implementation
Strategy = Input Validation
Construct HTTP headers very carefully, avoiding the use of non-validated input data.
Phase: Implementation
Strategy = Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use
a list of acceptable inputs that strictly conform to specifications. If an input does not strictly
conform to specifications, reject it or transform it into something that conforms. When performing
input validation, consider all potentially relevant properties, including length, type of input, the
full range of acceptable values, missing or extra inputs, syntax, consistency across related
fields, and conformance to business rules. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is not valid if the input
is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for
malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if
the code's environment changes. This can give attackers enough room to bypass the intended
validation. However, denylists can be useful for detecting potential attacks or determining which
inputs are so malformed that they should be rejected outright.
Phase: Implementation
Strategy = Output Encoding
Use and specify an output encoding that can be handled by the downstream component that
is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an
encoding is not specified, a downstream component may choose a different encoding, either
by assuming a default encoding or automatically inferring which encoding is being used, which
can be erroneous. When the encodings are inconsistent, the downstream component might
treat some character or byte sequences as special, even if they are not special in the original
encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks;
they even might be able to bypass protection mechanisms that assume the original encoding is
also being used by the downstream component.
CWE Version 4.14
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response
Splitting')
CWE-113: Improper Neutralization of CRLF Sequences
in HTTP Headers ('HTTP Request/Response Splitting') 274
Phase: Implementation
Strategy = Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation
before being validated (CWE-180). Make sure that the application does not decode the same
input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by
introducing dangerous inputs after they have been checked.
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.
Example Language: Java (Bad)
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:
Example Language: (Result)
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
However, because the value of the cookie is composed 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
Example Language: (Attack)
Wiley Hacker\r\nHTTP/1.1 200 OK\r\n
then the HTTP response would be split into two responses of the following form:
Example Language: (Result)
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
The second response is completely controlled by the attacker and can be constructed with any
header and body content desired. The ability 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:
CWE Version 4.14
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response
Splitting')
CWE-113: Improper Neutralization of CRLF Sequences
in HTTP Headers ('HTTP Request/Response Splitting')