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 an 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 exploiting 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:
- XSS or Cross-Site Scripting vulnerabilities
- Proxy and web server cache poisoning
- Website defacement
- Hijacking the client’s session
- Client web browser poisoning
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:
Hello, World<CR><LF>DATABASE ERROR: TABLE CORRUPTION
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:
fname<CR><LF>/bin/rm -rf /
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 CRLF Injections
Fortunately, CRLF injections are easy to prevent:
- Always follow the rule of never trusting user input.
- Sanitize and neutralize all user-supplied data or properly encode output in HTTP headers that would otherwise be visible to users in order to prevent the injection of CRLF sequences and their consequences.