Home > CAPEC List > CAPEC-34: HTTP Response Splitting (Version 2.11)  

CAPEC-34: HTTP Response Splitting

 
HTTP Response Splitting
Definition in a New Window Definition in a New Window
Attack Pattern ID: 34
Abstraction: Detailed
Status: Draft
Completeness: Complete
Presentation Filter:
+ 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.

+ Attack Steps
Explore
  1. Spider: Using a browser or an automated tool, an adversary 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.

    Use a spidering tool to follow and record all links and analyze the web pages 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.).

    Use a proxy tool to record all links visited during a manual traversal of the web application.

    Use a browser to manually explore the website and analyze how it is constructed. Many browsers' plugins are available to facilitate the analysis or automate the discovery.

Experiment
  1. Attempt variations on input parameters: The adversary 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.

    Use CR\LF characters (encoded or not) in the payloads in order to see if the HTTP header can be split.

    Use a proxy tool to record the HTTP responses headers.

Exploit
  1. Cross-Site Scripting: As the adversary succeeds in exploiting the vulnerability, they 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.

    Inject cross-site scripting payload preceded by response splitting syntax (CR/LF) into user-controllable input identified as vulnerable in the Experiment Phase.

  2. Cache poisoning:

    The adversary decides to target the cache server by forging new responses. 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.

+ Attack Prerequisites
  • User-controlled input used as part of HTTP header

  • Ability of adversary 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

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: High

The adversary 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: No specialized resources are required to execute this type of attack.

+ Probing Techniques

With available source code, the adversary 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 adversary 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
ScopeTechnical ImpactNote
Confidentiality
Integrity
Availability
Execute unauthorized code or commands
Run Arbitrary Code
Confidentiality
Access_Control
Authorization
Gain privileges / assume identity
+ 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 adversary.

+ Relevant Security Requirements

All client-supplied input must be validated through filtering and all output must be properly escaped.

+ Purposes
  • Penetration
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability 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
SubmitterOrganizationDateSource
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
Modifications
ModifierOrganizationDateCommentsSource
CAPEC Content TeamThe MITRE Corporation2017-08-04Updated Attack_Phases, Attack_Prerequisites, Attacker_Skills_or_Knowledge_Required, Description Summary, Payload_Activation_Impact, Probing_Techniques, Related_Attack_Patterns, Resources_RequiredInternal

More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2017