HTTP Response Splitting

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.


CRLF Injection

CRLF refers to the special character elements "Carriage Return" and "Line Feed". These elements are embedded in HTTP headers and other software code to signify an End of Line (EOL) marker. Many internet protocols, including MIME (e-mail), NNTP (newsgroups) and more importantly HTTP use CRLF sequences to split text streams into discrete elements. Web application developers split HTTP and other headers based on where CRLF is located. Exploits occur when an attacker is able to inject a CRLF sequence into an HTTP stream. By introducing this unexpected CRLF injection, the attacker is able to maliciously exploit CRLF vulnerabilities in order to manipulate the web application's functions.

A more formal name for CRLF Injection is Improper Neutralization of CRLF Sequences. Because CRLF injection is frequently used to split HTTP responses, it can also be designated as HTTP Response Splitting or Improper Neutralization of CRLF Sequences in HTTP Headers.


Key Concepts of CRLF Injection

CRLF Injection is a software application coding vulnerability that occurs when an attacker injects a CRLF character sequence where it is not expected. When CRLF Injection is used to split a HTTP response header it is referred to as HTTP Response Splitting. CRLF Injection vulnerabilities result from data input that is not neutralized, incorrectly neutralized, or otherwise unsanitized.

Attackers provide specially crafted text streams with CRLF injections in order to trick the web application to perform unexpected and potentially harmful actions ranging from medium to high severity. Attackers exploit the CRLF Injection vulnerability by injecting CRLF sequences in order to split a text stream to embed text sequences that the web application is not expecting. These unexpected CRLF injections can result in a security breach and cause material harm.

CRLF Injection exploits security vulnerabilities at the application layer. By exploting the CRLF Injection flaw in an HTTP response for example, attackers can modify application data compromising integrity and enabling the exploitation of the following vulnerabilities:


Explaining CRLF Injection Through Examples

Let's examine how CRLF Injections cause damage by looking at one of the most basic example of a CRLF attack: adding fake entries into log files. Suppose a vulnerable application accepts unsanitized or improperly neutralized data and writes it to a system log file. An attacker supplies the following input:

Because this error is fake, a sysadmin may waste a lot of time troubleshooting a non-existent error. An attacker could use this type of Trojan to distract the admin while attacking the system somewhere else.

Another way to illustrate how CRLF Injections can cause severe harm is through an application that accepts a file name as user input and then executes a relatively harmless command on that file such as "ls –a ." If the application is vulnerable to CRLF injection because of improperly neutralized or unsanitized data input, an attacker could provide the following input:

This CRLF Injection attack could wipe out the entire file system if the application were running with root privileges on a linux/unix system!


Preventing HTTP Response Splitting Vulnerabilities

Fortunately, HTTP response splitting are easy to prevent: