Jump to content

HTTP response splitting

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by RossPatterson (talk | contribs) at 14:53, 1 December 2007 (Moved template from HTTP Response splitting). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
  • From other capitalisation: This is a redirect from a title with another method of capitalisation. It leads to the title in accordance with the Wikipedia naming conventions for capitalisation, or it leads to a title that is associated in some way with the conventional capitalisation of this redirect title. This may help writing, searching and international language issues.
    • If this redirect is an incorrect capitalisation, then {{R from miscapitalisation}} should be used instead, and pages that use this link should be updated to link directly to the target. Miscapitalisations can be tagged in any namespace.
    • Use this rcat to tag only mainspace redirects; when other capitalisations are in other namespaces, use {{R from modification}} instead.

HTTP response splitting is a form of web application vulnerability, resulting from the failure of the application or its environment to properly sanitize input values. It can be used to perform cross-site scripting attacks, cross-user defacement, Web cache poisoning, and similar exploits.

The attack consists of making the server print a carriage return (CR, ASCII 0x0D) line feed (LF, ASCII 0x0A) sequence followed by content supplied by the attacker in the header section of its response, typically by including them in input fields sent to the application. Per the HTTP standard (RFC 2616), headers are separated by one CRLF and the response's headers are separated from its body by two. Therefore, the failure to remove CRs and LFs allows the attacker to set arbitrary headers, take control of the body, or break the response into two or more separate responses (hence the name).

Prevention

The generic solution is to URL-encode strings before inclusion into HTTP headers such as Location or Set-Cookie.

Typical examples of sanitization include casting to integer, or aggressive regular expression replacement. It is worth noting that although this is not a PHP specific problem, the PHP interpreter contains protection against this attack since version 4.4.2 and 5.1.2.[1]

References