CAPEC-34 - HTTP Response Splitting
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:
Severity
Likelihood
Confidentiality
Integrity
Availability
- Attack Methods 2
- Injection
- Protocol Manipulation
- Purposes 1
- Penetration
- Sec Principles 1
- Reluctance to Trust
- Scopes 2
- Execute unauthorized code or commands
- Availability
- Integrity
- Confidentiality
- Gain privileges / assume identity
- Authorization
- Access_Control
- Confidentiality
High level: 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.
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
None
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.
Never trust user-supplied input.
Step 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..
Tecnique ID: 1 - Environment(s) env-Web
Tecnique ID: 2 - Environment(s) env-Web
Tecnique ID: 3 - Environment(s) env-Web
Indicator ID: 1 - Environment(s) env-Web
Type: Positive
Inputs are transported through HTTP
Indicator ID: 2 - Environment(s) env-Web
Type: Positive
The application uses redirection techniques (HTTP Location, etc.)
Indicator ID: 3 - Environment(s) env-Web
Type: Inconclusive
Using URL rewriting, parameters may be part of the URL path.
Indicator ID: 4 - Environment(s) env-Web
Type: Inconclusive
No parameters appear to be used on the current page. Even though none appear, the web application may still use them if they are provided.
Indicator ID: 5 - Environment(s) env-Web
Type: Negative
Applications that have only static pages or that simply present information without accepting input are unlikely to be susceptible.
Security Control ID: 1
Type: 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).
Security Control ID: 2
Type: 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.
Security Control ID: 3
Type: Preventative
Use CAPTCHA to prevent the use of the application by an automated tool.
Security Control ID: 4
Type: Preventative
Actively monitor the application and either deny or redirect requests from origins that appear to be automated.
Outcome ID: 1
Type: Success
A list of user-controllable input entry points is created by the attacker.
Step 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..
Tecnique ID: 1 - Environment(s) env-Web
Tecnique ID: 2 - Environment(s) env-Web
Indicator ID: 1 - Environment(s) env-Web
Type: Positive
The web server uses unvalidated user-controlled input as part of the response headers
Security Control ID: 1
Type: 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.
Security Control ID: 2
Type: Preventative
Do not use user-controllable inputs in HTTP headers
Security Control ID: 3
Type: Preventative
Filter CR/LF syntax out of any user-controllable input utilized in HTTP headers.
Security Control ID: 4
Type: Preventative
Actively monitor the application and either deny or redirect requests from origins that appear to be generating HTTP Response Splitting attacks.
Outcome ID: 1
Type: Success
The CR\LF characters are passed in the HTTP header and two responses are generated for a single request.
Outcome ID: 2
Type: Failure
All CR\LF characters are consistently re-encoded or stripped before being written in the HTTP header
Outcome ID: 3
Type: Inconclusive
The size of the payload is being limited by the server-side application.
Outcome ID: 4
Type: Inconclusive
Some sensitive characters are consistently encoded, but others are not.
Step 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..
Tecnique ID: 1 - Environment(s) env-Web
Security Control ID: 1
Type: Detective
Monitor server logs for consecutive suspicious HTTP request
Security Control ID: 2
Type: Preventative
Apply appropriate input validation to filter all user-controllable input of scripting syntax
Security Control ID: 3
Type: Preventative
Appropriately encode all browser output to avoid scripting syntax
Outcome ID: 1
Type: Success
The malicious script is executed within the user's context.
Step 2 - Cache poisoning
.
Tecnique ID: 1 - Environment(s) env-Web
Indicator ID: 1 - Environment(s) env-Web
Type: Positive
System performs caching of HTTP responses
Security Control ID: 1
Type: Detective
Monitor server logs for consecutive suspicious HTTP requests.
Security Control ID: 2
Type: Preventative
Apply appropriate input validation to filter all user-controllable input of scripting syntax
Security Control ID: 3
Type: Preventative
Appropriately encode all browser output to avoid scripting syntax
Outcome ID: 1
Type: Success
The attacker gets the users to be served with this cached malicious HTTP response.
All client-supplied input must be validated through filtering and all output must be properly escaped.
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.