How does a server know when a new header begins and the old one ends or when a line is terminated? Simple. In order to note the termination of a line, \r\n or %0D%0A characters are used. These characters refer to Carriage Return (\r) Line Feed (\n). The characters can (and are) used in HTTP responses. To note the end of a line, they can also be used in files.
Is it dangerous?
A Carriage Return Line Feed (CRLF) Injection vulnerability occurs when an attacker is able to inject these characters into an HTTP response header. When such an action is performed, these can lead to different vulnerabilities, including (but not limited to) HTTP response splitting.
This vulnerability is not very common, it was not included in the OWASP 2010, 2013 or 2017 versions, but it is something web developers should be aware of: when utilized, it can lead to various vulnerabilities like Cross-Site Scripting (XSS) and HTTP Response Splitting. And, like Cross-Site Scripting, SQL Injection and many other web application vulnerabilities, Carriage Return Line Feed can occur when input fields are not being sanitized or are being incorrectly sanitized.
How would an attack look like?
Now that I’ve explained what the Carriage Return Line Feed vulnerability is, I should probably show an anatomy of an attack too, right? Instead, this time I will answer the question the other way around: We will take a look at real world examples of vulnerable web applications. In December 2015, Shopify was susceptible to HTTP Response Splitting. Because Shopify did not validate a parameter called “shop”, it was discovered that an attacker would be able to modify the request that was being sent by adding \r\n (%0D%0A) – if the request was modified successfully, a new header would be generated. The generated header would be processed by a web application running Shopify – this could’ve led to a Cross-Site Scripting attack.
Carriage Return Line Feed can also by utilized by a nefarious party after (or during) an attack to fake log entries and hide their actions. Consider such a scenario:
You’ve developed a web application so that it would keep a rolling (say, a week, a month or two months) of logs. The logs look like this:
127.0.0.1 – /view?id=1 – 2018 January 01, 10:00
An attacker happens to be aware of that. After looking for security issues in your website, the attacker finds an SQL Injection flaw and starts exploiting it by providing all sorts of payloads. After some time, you find your web application logs looking like this:
/view?id= – 2018 January 01, 10:00
127.0.0.1 – 2018 January 01, 10:00
The logs look like this because a Carriage Return Line Feed payload was provided:
/view?id=%0D%0A127.0.0.1 – 2018 January 01, 10:00 – /view?id=Payload Here
In order to prevent security issues of this nature from being included in your web application, ensure all user-provided input is being properly sanitized, and refrain from allowing user input in HTTP Response Headers. If you absolutely have to though, ensure all Carriage Return (\r) and Line Feed (\n) characters and their encoded variants (%0D and %0A) are blocked.
Even though Carriage Return Line Feed is not included in any released OWASP version, in the hands of an attacker, these vulnerabilities are a very powerful tool because they can lead to a variety of other flaws including Cross-Site Scripting and HTTP Response Splitting. To keep your web application from being susceptible to this security vulnerability, make sure you sanitize all input supplied by a user and strip all CR (\r) and LF (\n) characters out of HTTP Response Headers.