CRLF Injection and HTTP Response Splitting Vulnerability

When a browser sends a request to the server, the server response contains HTTP headers along with HTML response, i.e., the actual website content. Between HTTP headers and HTML responses, there is a special combination of characters that separate them. These characters are called as a carriage return and line feed, or in short, CRLF. 
Web servers use CRLF to understand when a new HTTP header starts, and another one ends. CRLF characters are a standard HTTP/1.1 message, and hence, they can be used by any type of server, whether it is Apache or Microsoft IIS. 

What is CRLF Injection Vulnerability?

An attacker inserts CRLF characters in the user input to trick a target web server into thinking that an object has been terminated and another one has started. Though CRLF sequences do not have malicious characters, they can be used for malicious actions such as HTTP response splitting. 

CRLF in web applications

Consider that there is a log file in your web application’s admin panel. It shows the output stream in this pattern: IP – Time – Visited Path. 

If an attacker enters CRLF characters into an HTTP request, he may be able to change the contents of the output stream and add fake log entries. For example, 
Here, %0d and %0a are URL encoded forms of CRLF. After these characters are encoded and displayed by the application, the log entry will look like: 
By successfully exploiting CRLF injection vulnerability, an attacker can obfuscate his malicious actions by adding fake entries in the log data. This may get detected when log entries are being checked by an administrator manually, but since it appears to come from the localhost, it may not get detected at all. 

HTTP Response Splitting

As CRLF characters separate HTTP response and its body, a combination of CRLFCRLF will inform the browser that the header ends and the body begins. This will allow an attacker to write data inside the response body where HTML code is stored. Further, it can lead to cross-site scripting (XSS) vulnerability. 
For example, consider that an application has a custom header: 
The header is set through a parameter defined as a name. Without URL encoding, the value gets directly reflected inside the HTTP header, allowing an attacker to add the combination of CRLFCRLF for tricking the browser as to whether the request body starts. This way, the attacker is now able to insert data such as an XSS payload: 

Preventing CRLF Injection and HTTP Splitting Vulnerabilities

As a primary defense against these vulnerabilities, an administrator/developer shall not allow user inputs directly inside the response headers. In case if this is unavoidable, CRLF characters can be encoded using a function. Another important recommendation is to update your programming languages to versions that do not allow CRLF to be injected outside the functions that set HTTP headers.