New to CAPEC? Start Here
Home > CAPEC List > CAPEC-34: HTTP Response Splitting (Version 3.9)  

CAPEC-34: HTTP Response Splitting

Attack Pattern ID: 34
Abstraction: Detailed
View customized information:
+ Description

An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.

See CanPrecede relationships for possible consequences.

+ Extended Description

Malicious user input is injected into various standard and/or user defined HTTP headers within a HTTP Response through use of Carriage Return (CR), Line Feed (LF), Horizontal Tab (HT), Space (SP) characters as well as other valid/RFC compliant special characters, and unique character encoding.

A single HTTP response ends up being split as two or more HTTP responses by the targeted client HTTP agent parsing the original maliciously manipulated HTTP response. This allows malicious HTTP responses to bypass security controls in order to implement malicious actions and provide malicious content that allows access to sensitive data and to compromise applications and users. This is performed by the abuse of interpretation and parsing discrepancies in different intermediary HTTP agents (load balancer, reverse proxy, web caching proxies, application firewalls, etc.) or client HTTP agents (e.g., web browser) in the path of the malicious HTTP responses.

This attack is usually the result of the usage of outdated or incompatible HTTP protocol versions as well as lack of syntax checking and filtering of user input in the HTTP agents receiving HTTP messages in the path.

This differs from CAPEC-105 HTTP Request Splitting, which is usually an attempt to compromise a back-end HTTP agent via HTTP Request messages. HTTP Response Splitting is an attempt to compromise a client agent (e.g., web browser) by sending malicious content in HTTP responses from back-end HTTP infrastructure.

HTTP Smuggling (CAPEC-33 and CAPEC-273) is different from HTTP Splitting due to the fact it relies upon discrepancies in the interpretation of various HTTP Headers and message sizes and not solely user input of special characters and character encoding. HTTP Smuggling was established to circumvent mitigations against HTTP Request Splitting techniques.

+ Likelihood Of Attack

Medium

+ Typical Severity

High

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.220Client-Server Protocol Manipulation
PeerOfDetailed Attack PatternDetailed Attack Pattern - A detailed level attack pattern in CAPEC provides a low level of detail, typically leveraging a specific technique and targeting a specific technology, and expresses a complete execution flow. Detailed attack patterns are more specific than meta attack patterns and standard attack patterns and often require a specific protection mechanism to mitigate actual attacks. A detailed level attack pattern often will leverage a number of different standard level attack patterns chained together to accomplish a goal.105HTTP Request Splitting
CanPrecedeStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.63Cross-Site Scripting (XSS)
CanPrecedeMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.115Authentication Bypass
CanPrecedeStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.141Cache Poisoning
CanPrecedeMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.148Content Spoofing
CanPrecedeMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.154Resource Location Spoofing
CanPrecedeStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.593Session Hijacking
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
Explore
  1. Survey network to identify target: The adversary performs network reconnaissance by monitoring relevant traffic to identify the network path and parsing of the HTTP messages with the goal of identifying potential targets

    Techniques
    Scan networks to fingerprint HTTP infrastructure and monitor HTTP traffic to identify HTTP network path with a tool such as a Network Protocol Analyzer.
Experiment
  1. Identify vulnerabilities in targeted HTTP infrastructure and technologies: The adversary sends a variety of benign/ambiguous HTTP requests to observe responses from HTTP infrastructure in order to identify differences/discrepancies in the interpretation and parsing of HTTP requests by examining supported HTTP protocol versions, HTTP headers, syntax checking and input filtering.

  2. Cause differential HTTP responses by experimenting with identified HTTP Request vulnerabilities: The adversary sends maliciously crafted HTTP request to back-end HTTP infrastructure to inject adversary data (in the form of HTTP headers with custom strings and embedded web scripts and objects) into HTTP responses (intended for intermediary and/or front-end client/victim HTTP agents communicating with back-end HTTP infrastructure) for the purpose of interfering with the parsing of HTTP responses by intermediary and front-end client/victim HTTP agents. The intended consequences of the malicious HTTP request and the subsequent adversary injection and manipulation of HTTP responses to intermediary and front-end client/victim HTTP agents, will be observed to confirm applicability of identified vulnerabilities in the adversary's plan of attack.

    Techniques
    Continue the monitoring of HTTP traffic.

    Utilize different sequences of special characters (CR - Carriage Return, LF - Line Feed, HT - Horizontal Tab, SP - Space and etc.) to bypass filtering and back-end encoding and to embed:

    • additional HTTP Requests with their own headers
    • malicious web scripts into parameters of HTTP Request headers (e.g., browser cookies like Set-Cookie or Ajax web/browser object parameters like XMLHttpRequest)
    • adversary chosen encoding (e.g., UTF-7)

    to utilize additional special characters (e.g., > and <) filtered by the target HTTP agent.

    Note that certain special characters and character encoding may be applicable only to intermediary and front-end agents with rare configurations or that are not RFC compliant.

    Follow an unrecognized (sometimes a RFC compliant) HTTP header with a subsequent HTTP request to potentially cause the HTTP request to be ignored and interpreted as part of the preceding HTTP request.
Exploit
  1. Perform HTTP Response Splitting attack: Using knowledge discovered in the experiment section above, smuggle a message to cause one of the consequences.

    Techniques
    Leverage techniques identified in the Experiment Phase.
+ Prerequisites
A vulnerable or compromised server or domain/site capable of allowing adversary to insert/inject malicious content that will appear in the server's response to target HTTP agents (e.g., proxies and users' web browsers).
Differences in the way the two HTTP agents parse and interpret HTTP requests and its headers.
HTTP headers capable of being user-manipulated.
HTTP agents running on HTTP/1.0 or HTTP/1.1 that allow for Keep Alive mode, Pipelined queries, and Chunked queries and responses.
+ Skills Required
[Level: Medium]
Detailed knowledge on HTTP protocol: request and response messages structure and usage of specific headers.
[Level: Medium]
Detailed knowledge on how specific HTTP agents receive, send, process, interpret, and parse a variety of HTTP messages and headers.
[Level: Medium]
Possess knowledge on the exact details in the discrepancies between several targeted HTTP agents in path of an HTTP message in parsing its message structure and individual headers.
+ Resources Required
Tools capable of monitoring HTTP messages, and crafting malicious HTTP messages and/or injecting malicious content into HTTP messages.
+ Indicators
Differences in responses processed by the two agents with multiple responses to a single request in the web logs. This requires careful monitoring or a capable log analysis tool.
+ Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Execute Unauthorized Commands
Confidentiality
Access Control
Authorization
Gain Privileges
Integrity
Modify Data
+ Mitigations
Design: evaluate HTTP agents prior to deployment for parsing/interpretation discrepancies.
Configuration: front-end HTTP agents notice ambiguous requests.
Configuration: back-end HTTP agents reject ambiguous requests and close the network connection.
Configuration: Disable reuse of back-end connections.
Configuration: Use HTTP/2 for back-end connections.
Configuration: Use the same web server software for front-end and back-end server.
Implementation: Utilize a Web Application Firewall (WAF) that has built-in mitigation to detect abnormal requests/responses.
Configuration: Install latest vendor security patches available for both intermediary and back-end HTTP infrastructure (i.e. proxies and web servers)
Configuration: Ensure that HTTP infrastructure in the chain or network path utilize a strict uniform parsing process.
Implementation: Utilize intermediary HTTP infrastructure capable of filtering and/or sanitizing user-input.
+ Example Instances

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. See also: CVE-2006-0207

+ Notes

Relationship

HTTP Smuggling is an evolution of previous HTTP Splitting techniques which are commonly remediated against.

Terminology

HTTP Splitting – "the act of forcing a sender of (HTTP) messages to emit data stream consisting of more messages than the sender’s intension. The messages sent are 100% valid and RFC compliant" [REF-117].

Terminology

HTTP Smuggling – "the act of forcing a sender of (HTTP) messages to emit data stream which may be parsed as a different set of messages (i.e. dislocated message boundaries) than the sender’s intention. This is done by virtue of forcing the sender to emit non-standard messages which can be interpreted in more than one way" [REF-117].
+ Taxonomy Mappings
Relevant to the WASC taxonomy mapping
Entry IDEntry Name
25HTTP Response Splitting
+ References
[REF-1] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02.
[REF-680] Robert Auger. "HTTP Response Splitting". The Web Application Security Consortium. 2010. <http://projects.webappsec.org/w/page/13246931/HTTP%20Response%20Splitting>. URL validated: 2021-10-14.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2017-08-04
(Version 2.11)
CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases, Attack_Prerequisites, Attacker_Skills_or_Knowledge_Required, Description Summary, Payload_Activation_Impact, Probing_Techniques, Related_Attack_Patterns, Resources_Required
2018-07-31
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases, References
2020-07-30
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Execution_Flow
2020-12-17
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated Taxonomy_Mappings
2021-06-24
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Weaknesses
2021-10-21
(Version 3.6)
CAPEC Content TeamThe MITRE Corporation
Updated @Status, Consequences, Description, Example_Instances, Execution_Flow, Extended_Description, Indicators, Mitigations, Notes, Prerequisites, References, Related_Attack_Patterns, Related_Weaknesses, Resources_Required, Skills_Required, Taxonomy_Mappings
2022-09-29
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Extended_Description
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018