HTTP Response Splitting [CWE-113] — The Hacktivists

HTTP Response Splitting weakness describes improper neutralization of CRLF sequences in HTTP headers.

Table of Content
1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Severity and CVSS Scoring

1. Description
………………………………

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 the 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 the 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 an HTTP request, or when data is not validated before sending it back to the client in the 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 the client browser, so the HTTP response splitting attack is possible only when an application uses untrusted input to construct headers.

1.1 PERL
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
HOST: testhost.local
Referer: testhost.local
ACCEPT: */*
Accept-Encoding: None
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Connection: Close
Accept-Transfer-Encoding: None
HTTP/1.1 302 Found
Date: Fri, 07 Sep 2012 17:02:45 GMT
Server: Apache
Location: /index.html
Content-Length: 0
Connection: close
Content-Type: text/html; charset=Windows-1252

If an attacker sends CRLF characters to the 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
HOST: testhost.local
Referer: testhost.local
ACCEPT: */*
Accept-Encoding: None
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Connection: Close
Accept-Transfer-Encoding: None

1.2 ASP.NET
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 the web.config. Make sure this option is set to true.

1.3 PHP
PHP is not vulnerable to HTTP response splitting since version 5.1.2.

1.4 NodeJS
NodeJS is not vulnerable to HTTP response splitting since versions 5.6.0, 4.3.0, 0.12.10, 0.10.4.

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 the integrity of the application and is usually scored as:
5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N] — Medium severity.

Credits: https://www.immuniweb.com/