Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.
Header Manipulation vulnerabilities occur when:
1. Data enters a web application through an untrusted source, most frequently an HTTP request.
2. The data is included in an HTTP response header sent to a web user without being validated.
As with many software security vulnerabilities, Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.
One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.
Many of today's modern application servers will prevent the injection of malicious characters into HTTP headers. If your application server prevents setting headers with new line characters, then your application is not vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.
Example: The following code segment reads the location from an HTTP request and sets it in a the header its location field of an HTTP response.
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location
does not contain any CR and LF characters. If an attacker submits a malicious string, such as "index.html\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection
[2] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input
[3] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws
[4] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A6 Information Leakage and Improper Error Handling
[5] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A7 Insecure Cryptographic Storage
[6] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A8 Insecure Cryptographic Storage
[7] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A8 Insecure Storage
[8] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3150.1 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3620 CAT II
[12] Standards Mapping - FIPS200 - (FISMA) AU, SI
[13] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 113
[14] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 117
[15] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 310
[16] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 497
[17] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[18] D. Crab HTTP Response Splitting
[19] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) HTTP Response Splitting
[20] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Information Leakage
[21] Standards Mapping - FIPS200 - (FISMA) MP
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.8
[33] Standards Mapping - FIPS200 - (FISMA) SI