CAPEC

Common Attack Pattern Enumeration and Classification
Common Attack Pattern Enumeration and Classification

A Community Knowledge Resource for Building Secure Software

Home > CAPEC List > Individual CAPEC Dictionary Definition (Release 1.1)   View the CAPEC List

Individual CAPEC Dictionary Definition (Release 1.1)
Individual CAPEC Dictionary Definition (Release 1.1)

HTTP Response Splitting
Attack Pattern ID
Pattern Abstraction: Detailed

34

Typical Severity

High

Description

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

  1. 1. Identifies the user-controllable input that causes arbitrary HTTP header injection.

  2. 2. Crafts a malicious input consisting of data to terminate the original response and start a second response with headers controlled by the attacker.

  3. 3. Causes the victim to send two requests to the server. The first request consists of maliciously crafted input to be used as part of HTTP response headers and the second is a dummy request so that the victim interprets the split response as belonging to the second request.

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 Likelihood of Exploit

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 Vulnerability

CVE-2006-0207

Attacker Skill or Knowledge Required

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
  • Run Arbitrary Code
  • Privilege Escalation
Context Description

HTTP Response Splitting attacks take place where the server script embeds user-controllable data in HTTP response headers. This typically happens when the script embeds such data in the redirection URL of a redirection response (HTTP status code 3xx), or when the script embeds usuch data in a cookie value or name when the response sets a cookie. In the first case, the redirection URL is part of the Location HTTP response header, and in the cookie setting, the cookie name/value pair is part of the Set-
Cookie HTTP response header.

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-IDWeakness NameWeakness Relationship Type
113Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')Targeted
74Failure to Sanitize Data into a Different Plane (aka 'Injection')Secondary
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.
Purpose

Penetration

CIA Impact
Confidentiality ImpactIntegrity ImpactAvailability Impact
HighHighLow
Technical Context
Architectural ParadigmFrameworkPlatformLanguage
Client-ServerAllAllAll
References

G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.

CWE - HTTP Response Splitting

CWE - Injection

Source
Submission(s)
SubmitterOrganizationDateComment
Chiradeep B Chhaya2007-01-09First Draft
Modification(s)
ModifierOrganizationDateComment
Malik HamroCigital, Inc2007-02-27Reformat to new schema and review
Sean BarnumCigital, Inc2007-03-05Review and revise
Richard StruseVOXEM, Inc2007-03-26Review and feedback leading to changes in Description
Sean BarnumCigital, Inc2007-04-13Modified pattern content according to review and feedback
 
Page Last Updated: April 18, 2008