- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
HTTP Response Splitting [CWE-113]
This weakness describes improper neutralization of CRLF sequences in HTTP headers.
Created: September 11, 2012
Latest Update: August 5, 2015
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Severity and CVSS Scoring
- Vulnerability Remediation Techniques and Examples
This weakness occurs when software accepts data from an upstream provider, but does not neutralize or incorrectly neutralizes CR and LF characters before including data into HTTP response headers. This provides an attacker with ability to inject arbitrary headers into the HTTP response, which is sent to a client. As a result an attacker might be able to modify contents of the HTTP response by means of unexpected CR (carriage return - %0d or \r) and LF (line feed - %0a or \n) characters and send to the browser two different HTTP responses instead of one. The attacker, who controls the second HTTP response, can perform different attacks such as cache poisoning and cross-site scripting.
HTTP response splitting might occur when an application receives data from an untrusted source, such as HTTP request, or when data is not validated before sending it back to the client in HTTP response. Modern programming languages have built-in protection mechanisms against HTTP response splitting that do not allow sending more than one response header to client browser, so the HTTP response splitting attack is possible only when application uses untrusted input to construct headers.
The following example works with PERL and demonstrates the vulnerable code:
- use CGI qw(:standard);
- my $value = param('cookie');
- print "Content-type: text/plain\n";
- print "Set-Cookie: cookie=$value\n";
The example below redirects users to the address passed via the "page" parameter. The client sends the following header and receives the HTTP 302 response:
GET /test.pl?page=/index.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
HTTP/1.1 302 Found
Date: Fri, 07 Sep 2012 17:02:45 GMT
Content-Type: text/html; charset=Windows-1252
If an attacker sends CRLF characters to vulnerable "page" parameter, he can split the header and make the client browser execute arbitrary HTML and script code:
GET /test.pl?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3ECSRF%3C/font%3E%3C/html%3E HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
With ASP.NET 2.0 this attack is almost impossible, because the "\r\n" sequences are disallowed by default in methods that involve HTTP response headers. It is possible though to turn off HTTP response splitting protection by disabling the "enableHeaderChecking" option in web.config. Make sure this option is set to true.
PHP is not vulnerable to HTTP response splitting since version 5.1.2.
2. Potential impact
An attacker might be able to perform cross-site scripting, phishing and cache poisoning attacks. This weakness is a significant threat for high load servers that use caching proxies to deliver content to the end-users. One request sent by an attacker can be cached and displayed to all visitors of a webpage. As a result, an attacker might be able to gain access to potentially sensitive data and perform different attacks against website users.
3. Attack patterns
CAPEC has the following patterns for this weakness:
- CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
- CAPEC-34: HTTP Response Splitting
- CAPEC-63: Simple Script Injection
- CAPEC-85: Client Network Footprinting (using AJAX/XSS)
This weakness is described in WASC classification as four separate techniques:
- WASC-27: HTTP Response Smuggling
- WASC-25: HTTP Response Splitting
- WASC-26: HTTP Request Smuggling
- WASC-24: HTTP Request Splitting
4. Affected software
Any software that uses input data to construct headers is potentially vulnerable to this weakness. In most cases these are web applications, web servers, caching proxies.
5. Severity and CVSS Scoring
Depending on potential damage this weakness could impact integrity of the application and is usually scored as:
4.3 (AV:N/AC:M/Au:N/C:N/I:P/A:N) – Medium severity.
We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.
All input passed to the application must be considered untrustworthy and should be handled as such. Use a good known input validation strategy based on whitelists to construct headers and do not rely exclusively on looking for malicious or malformed inputs. All input should be decoded and canonicalized to the application's current internal representation.
7. Vulnerability Remediation Techniques and Examples
Usage of the
header() function for HTTP headers output is safe in modern PHP versions.
With ASP.NET 2.0 this attack is impossible, the "
\r\n" sequences are disallowed by default.
- param = re.sub("[^\\n\\r]+", "_", param)
- url = url.replaceAll("\\n\\r","");
These are general recommendations. Every case must be treated separately.
Caution: do not blindly copy-paste the above-mentioned solutions into your application code. In some cases this may result in incorrect behavior of the application or inconsistent patch. Carefully read the References or consult security specialists in case you are not sure how to patch a vulnerability.
- CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') [cwe.mitre.org]
- HTTP Response Splitting [www.owasp.org]
- HTTP Response Splitting Attack [resources.infosecinstitute.com]
- Introduction to HTTP Response Splitting [www.securiteam.com]
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.↑ Back to Top