CAPEC 34

Summary

Attack Execution Flow

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.

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	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.).	env-Web
   2	Use a proxy tool to record all links visited during a manual traversal of the web application.	env-Web
   3	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.	env-Web

   Indicators

   ID	type	Indicator Description	Environments
   1	Positive	Inputs are transported through HTTP	env-Web
   2	Positive	The application uses redirection techniques (HTTP Location, etc.)	env-Web
   3	Inconclusive	Using URL rewriting, parameters may be part of the URL path.	env-Web
   4	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.	env-Web
   5	Negative	Applications that have only static pages or that simply present information without accepting input are unlikely to be susceptible.	env-Web

   Outcomes

   ID	type	Outcome Description
   1	Success	A list of user-controllable input entry points is created by the attacker.

   Security Controls

   ID	type	Security Control Description
   1	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).
   2	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.
   3	Preventative	Use CAPTCHA to prevent the use of the application by an automated tool.
   4	Preventative	Actively monitor the application and either deny or redirect requests from origins that appear to be automated.

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.

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	Use CR\LF characters (encoded or not) in the payloads in order to see if the HTTP header can be split.	env-Web
   2	Use a proxy tool to record the HTTP responses headers.	env-Web

   Indicators

   ID	type	Indicator Description	Environments
   1	Positive	The web server uses unvalidated user-controlled input as part of the response headers	env-Web

   Outcomes

   ID	type	Outcome Description
   1	Success	The CR\LF characters are passed in the HTTP header and two responses are generated for a single request.
   2	Failure	All CR\LF characters are consistently re-encoded or stripped before being written in the HTTP header
   3	Inconclusive	The size of the payload is being limited by the server-side application.
   4	Inconclusive	Some sensitive characters are consistently encoded, but others are not.

   Security Controls

   ID	type	Security Control Description
   1	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.
   2	Preventative	Do not use user-controllable inputs in HTTP headers
   3	Preventative	Filter CR/LF syntax out of any user-controllable input utilized in HTTP headers.
   4	Preventative	Actively monitor the application and either deny or redirect requests from origins that appear to be generating HTTP Response Splitting attacks.

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.

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	SecurityDatabase\Alert\Inject cross-site scripting payload preceded by response splitting syntax (CR/LF) into user-controllable input identified as vulnerable in the Experiment Phase.	env-Web

   Outcomes

   ID	type	Outcome Description
   1	Success	The malicious script is executed within the user's context.

   Security Controls

   ID	type	Security Control Description
   1	Detective	Monitor server logs for consecutive suspicious HTTP request
   2	Preventative	Apply appropriate input validation to filter all user-controllable input of scripting syntax
   3	Preventative	Appropriately encode all browser output to avoid scripting syntax

2. Cache poisoning:

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	The attacker 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.	env-Web

   Indicators

   ID	type	Indicator Description	Environments
   1	Positive	System performs caching of HTTP responses	env-Web

   Outcomes

   ID	type	Outcome Description
   1	Success	The attacker gets the users to be served with this cached malicious HTTP response.

   Security Controls

   ID	type	Security Control Description
   1	Detective	Monitor server logs for consecutive suspicious HTTP requests.
   2	Preventative	Apply appropriate input validation to filter all user-controllable input of scripting syntax
   3	Preventative	Appropriately encode all browser output to avoid scripting syntax

Likelihood: Medium

Description

Related Vulnerabilities

Skill or Knowledge Level: 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.

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.

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

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.

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

CWE - HTTP Response Splitting

CWE - Injection