CAPEC Details
Name HTTP Response Splitting
Likelyhood of attack Typical severity
Medium High
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.
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
Execution Flow
Step Phase Description Techniques
1 Explore [Spider] Using a browser or an automated tool, an adversary follows all public links on a web site. They record 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.
2 Experiment [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. They record all the responses from the server that include unmodified versions of their 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.
3 Exploit [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.
4 Exploit [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.
  • 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.
Solutions 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.
Related Weaknesses
CWE ID Description
CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
CWE-697 Incorrect Comparison
CWE-707 Improper Neutralization
CWE-713 OWASP Top Ten 2007 Category A2 - Injection Flaws
Related CAPECS
CAPEC ID Description
CAPEC-220 An adversary takes advantage of weaknesses in the protocol by which a client and server are communicating to perform unexpected actions. Communication protocols are necessary to transfer messages between client and server applications. Moreover, different protocols may be used for different types of interactions. For example, an authentication protocol might be used to establish the identities of the server and client while a separate messaging protocol might be used to exchange data. If there is a weakness in a protocol used by the client and server, an attacker might take advantage of this to perform various types of attacks. For example, if the attacker is able to manipulate an authentication protocol, the attacker may be able spoof other clients or servers. If the attacker is able to manipulate a messaging protocol, the may be able to read sensitive information or modify message contents. This attack is often made easier by the fact that many clients and servers support multiple protocols to perform similar roles. For example, a server might support several different authentication protocols in order to support a wide range of clients, including legacy clients. Some of the older protocols may have vulnerabilities that allow an attacker to manipulate client-server interactions.
Taxonomy: WASC
Entry ID Entry Name
25 HTTP Response Splitting
Taxonomy: OWASP Attacks
Entry ID Entry Name
Link HTTP Response Splitting