CAPEC-34: HTTP Response Splitting

HTTP Response Splitting

Attack Pattern ID: 34 Status: Draft
Abstraction: Detailed Completeness: Complete

Summary
This attack uses a maliciously-crafted HTTP request in order to cause a vulnerable
web server to respond with an HTTP response stream that will be interpreted by the
client as two separate responses instead of one. This is possible when user-controlled
input is used unvalidated as part of the response headers. The target software, the
client, will interpret the injected header as being a response to a second request,
thereby causing the maliciously-crafted contents be displayed and possibly cached.
To achieve HTTP Response Splitting on a vulnerable web server, the attacker:

Attack Execution Flow

Explore
1. Spider:
Using a browser or an automated tool, an attacker follows all public links on a web site.
He records all the links, the forms and all potential user-controllable input points for the
web application.
Attack Step Techniques
ID Attack Step Technique Description Environments
1 Use a spidering tool to follow and record all links and analyze the web pages env-Web
to find entry points. Make special note of any links that include parameters in
the URL, forms found in the pages (like file upload, etc.).
2 Use a proxy tool to record all links visited during a manual traversal of the env-Web
web application.
3 Use a browser to manually explore the website and analyze how it is env-Web
constructed. Many browsers' plugins are available to facilitate the analysis or
automate the discovery.

Indicators
ID Type Indicator Description Environments
1 Positive Inputs are transported through HTTP env-Web

2 Positive The application uses redirection techniques (HTTP Location, env-Web

etc.)
3 Inconclusive Using URL rewriting, parameters may be part of the URL path. env-Web

4 Inconclusive No parameters appear to be used on the current page. Even env-Web

though none appear, the web application may still use them if
they are provided.
5 Negative Applications that have only static pages or that simply present env-Web
information without accepting input are unlikely to be
susceptible.

Outcomes
ID Type Outcome Description
1 Success A list of user-controllable input entry points is created by the attacker.

Security Controls
ID Type Security Control Description
1 Detective Monitor velocity of page fetching in web logs. Humans who view a page and select
a link from it will click far slower and far less regularly than tools. Tools make
 requests very quickly and the requests are typically spaced apart regularly (e.g.
0.8 seconds between them).
2 Detective Create links on some pages that are visually hidden from web browsers. Using
iframes, images, or other HTML techniques, the links can be hidden from web
browsing humans, but visible to spiders and programs. A request for the page,
then, becomes a good predictor of an automated tool probing the application.
3 Preventative Use CAPTCHA to prevent the use of the application by an automated tool.
4 Preventative Actively monitor the application and either deny or redirect requests from origins
that appear to be automated.
Experiment
1. Attempt variations on input parameters:
The attacker injects the entry points identified in the Explore Phase with response
splitting syntax and variations of payloads to be acted on in the additional response. He
records all the responses from the server that include unmodified versions of his payload.
Attack Step Techniques
ID Attack Step Technique Description Environments
1 Use CR\LF characters (encoded or not) in the payloads in order to see if the env-Web
HTTP header can be split.
2 Use a proxy tool to record the HTTP responses headers. env-Web

Indicators
ID Type Indicator Description Environments
1 Positive The web server uses unvalidated user-controlled input as part of env-Web
the response headers

Outcomes
ID Type Outcome Description
1 Success The CR\LF characters are passed in the HTTP header and two responses are
generated for a single request.
2 Failure All CR\LF characters are consistently re-encoded or stripped before being written
in the HTTP header
3 Inconclusive The size of the payload is being limited by the server-side application.
4 Inconclusive Some sensitive characters are consistently encoded, but others are not.

Security Controls
ID Type Security Control Description
1 Detective Monitor input to web servers (not only GET, but all in the inputs), application
servers, and other HTTP infrastructure (e.g., load balancers). Alert on CR\LF
characters.
2 Preventative Do not use user-controllable inputs in HTTP headers
3 Preventative Filter CR/LF syntax out of any user-controllable input utilized in HTTP headers.
4 Preventative Actively monitor the application and either deny or redirect requests from origins
that appear to be generating HTTP Response Splitting attacks.

Exploit

1. Cross-Site Scripting:
As the attacker succeeds in exploiting the vulnerability, he can choose to attack the user
with Cross-Site Scripting. The possible outcomes of such an attack are described in the
Cross-Site Scripting related attack patterns.
Attack Step Techniques
ID Attack Step Technique Description Environments
 1 Inject cross-site scripting payload preceded by response splitting syntax env-Web
(CR/LF) into user-controllable input identified as vulnerable in the Experiment
Phase.

Outcomes
ID Type Outcome Description
1 Success The malicious script is executed within the user's context.

Security Controls
ID Type Security Control Description
1 Detective Monitor server logs for consecutive suspicious HTTP request
2 Preventative Apply appropriate input validation to filter all user-controllable input of scripting
syntax
3 Preventative Appropriately encode all browser output to avoid scripting syntax

2. Cache poisoning:
Attack Step Techniques
ID Attack Step Technique Description Environments
1 The attacker decides to target the cache server by forging new responses. env-Web
The server will then cache the second request and response. The cached
response has most likely an attack vector like Cross-Site Scripting; this
attack will then be serve to many clients due to the caching system.

Indicators
ID Type Indicator Description Environments
1 Positive System performs caching of HTTP responses env-Web

Outcomes
ID Type Outcome Description
1 Success The attacker gets the users to be served with this cached malicious HTTP response.

Security Controls
ID Type Security Control Description
1 Detective Monitor server logs for consecutive suspicious HTTP requests.
2 Preventative Apply appropriate input validation to filter all user-controllable input of scripting
syntax
3 Preventative Appropriately encode all browser output to avoid scripting syntax

Attack Prerequisites
 User-controlled input used as part of HTTP header
 Ability of attacker to inject custom strings in HTTP header
 Insufficient input validation in application to check for input sanity before using it
as part of response header
Typical Severity
High
Typical Likelihood of Exploit
Likelihood: Medium
Methods of Attack

 Injection
 Protocol Manipulation
 Examples-Instances
Description
In the PHP 5 session extension mechanism, a user-supplied session ID is sent back
to the user within the Set-Cookie HTTP header. Since the contents of the user-
supplied session ID are not validated, it is possible to inject arbitrary HTTP headers
into the response body. This immediately enables HTTP Response Splitting by simply
terminating the HTTP response header from within the session ID used in the Set-
Cookie directive.
Related Vulnerabilities
CVE-2006-0207
Attacker Skills or Knowledge Required
Skill or Knowledge Level: High
The attacker needs to have a solid understanding of the HTTP protocol and HTTP
headers and must be able to craft and inject requests to elicit the split responses.
Resources Required
None
Probing Techniques
With available source code, the attacker can see whether user input is validated or
not before being used as part of output. This can also be achieved with static code
analysis tools
If source code is not available, the attacker can try injecting a CR-LF sequence
(usually encoded as %0d%0a in the input) and use a proxy such as Paros to
observe the response. If the resulting injection causes an invalid request, the web
server may also indicate the protocol error.
Indicators-Warnings of Attack
The only indicators are multiple responses to a single request in the web logs.
However, this is difficult to notice in the absence of an application filter proxy or a
log analyzer. There are no indicators for the client
Solutions and Mitigations
To avoid HTTP Response Splitting, the application must not rely on user-controllable
input to form part of its output response stream. Specifically, response splitting
occurs due to injection of CR-LF sequences and additional headers. All data arriving
from the user and being used as part of HTTP response headers must be subjected
to strict validation that performs simple character-based as well as semantic
filtering to strip it of malicious character sequences and headers.
Attack Motivation-Consequences
Scope Technical Impact Note
Confidentiality Execute unauthorized code or commands Run Arbitrary Code
Integrity
Availability
Confidentiality Gain privileges / assume identity
Access_Control
Authorization
Injection Vector
User-controllable input that forms part of output HTTP response headers
Payload
Encoded HTTP header and data separated by appropriate CR-LF sequences. The
injected data must consist of legitimate and well-formed HTTP headers as well as
required script to be included as HTML body.
Activation Zone
API calls in the application that set output response headers.
 Payload Activation Impact
The impact of payload activation is that two distinct HTTP responses are issued to
the target, which interprets the first as response to a supposedly valid request and
the second, which causes the actual attack, to be a response to a second dummy
request issued by the attacker.
Related Weaknesses
CWE-ID Weakness Name Weakness Relationship Type
113 Improper Neutralization of CRLF Sequences in HTTP Targeted
Headers ('HTTP Response Splitting')
697 Insufficient Comparison Targeted
707 Improper Enforcement of Message or Data Structure Targeted
713 OWASP Top Ten 2007 Category A2 - Injection Flaws Targeted
74 Improper Neutralization of Special Elements in Secondary
Output Used by a Downstream Component
('Injection')
Related Attack Patterns
Nature Type ID Name
ChildOf 220 Client-Server Protocol Manipulation 1000
HasMember 358 WASC-25 - HTTP Response Splitting 333
Relevant Security Requirements
All client-supplied input must be validated through filtering and all output must be
properly escaped.
Related Security Principles
 Reluctance to Trust
Related Guidelines
 Never trust user-supplied input.
Purposes

 Penetration

CIA Impact
Confidentiality Impact: High Integrity Impact: High Availability Impact: Low
Technical Context

Architectural Paradigms Client-Server n-Tier

Frameworks All
Platforms All
Languages All
References
[R.34.1] [REF-2] G. Hoglund and G. McGraw. "Exploiting Software: How to Break
Code". Addison-Wesley. February 2004.
[R.34.2] [REF-3] "Common Weakness Enumeration (CWE)". CWE-113 - HTTP
Response Splitting. Draft. The MITRE Corporation. 2007.
<http://cwe.mitre.org/data/definitions/113.html>.
[R.34.3] [REF-3] "Common Weakness Enumeration (CWE)". CWE-74 - Injection.
Draft. The MITRE Corporation. 2007. <http://cwe.mitre.org/data/definitions/74.html>.
Content History
Submissions
Submitter Organization Date Source

CAPEC Content Team The MITRE Corporation 2014-06-23 Internal_CAPEC_Team