CRLF is the acronym used to refer to Carriage Return (\r) Line Feed (\n). As one might notice from the symbols in the brackets, “Carriage Return” refers to the end of a line, and “Line Feed” refers to the new line. Hence, both CR and LF are used to denote the ending point of a line. When a user requests content on a website, the server returns the website content along with the HTTP headers. The headers and the contents are separated by a defined combination of CR and LF. It is because of CRLF that a server knows where a new header begins or ends. A Carriage Return Line Feed (CRLF) Injection vulnerability is a type of Server Side Injection which occurs when an attacker inserts the CRLF characters in an input field to deceive the server by making it think that an object has terminated and a new one has begun. This happens when the web application doesn’t sanitize user input for CRLF characters. It has a medium severity rating (P3 according to Bugcrowd’s VRT).

CRLF Injection attack has two most important use cases:

• Log Splitting: The attacker inserts an end of line character and an extra line to falsify the log file entries in order to deceive the system administrators by hiding other attacks.
• HTTP Response Splitting: CRLF injection is used to add HTTP headers to the HTTP response and, for example, perform an XSS attack that leads to information disclosure.

Example: 

A simple GET request can be crafted as follows:

Note: %0d and %0a are encoded forms of \r and \n respectively. If the web application is vulnerable, an attacker will be able to set a cookie on the website. 

Impacts of CRLF injection

CRLF Injection allows the attacker to set fake cookies, steal CSRF tokens, disclose user information by injecting a script (XSS) and perform a variety of other attacks. It also allows attackers to deactivate & bypass security measures like XSS filters & Same Origin Policy (SOP), making them susceptible to the following attacks:

1. XSS or Cross Site Scripting
XSS or Cross Site Scripting is a security vulnerability which allows an attacker to inject malicious JavaScript code into the web application. The following GET requests are crafted in an attempt chain CRLF Injection with XSS. 
By Popping an alert containing sensitive user information 

www.target.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

By Disabling XSS Protection 

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2. Cookie Injection
HTTP Response Splitting allows an attacker to set malicious cookies on the victim’s browser. In most cases, the following GET request will result in a 307 Redirect, and thus the victim will be redirected to target.com & the URL won’t contain the Set-Cookie parameter. In the background however, the cookie will be set. 

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. Phishing Attacks
An attacker can set the Location header which would redirect the victim to the evil website. This website can be developed to look just like the target website and when the victim enters their credentials, they’ll be sent to the attacker. The location header can be set as:

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4. Session Fixation
Similar to the Cookie Injection attack, here the attacker sets a user’s session id to a particular value. This link is sent to the victim and when the victim logs in using this session, the attacker can also log in by using the same session id. 

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. HTTP Header Injection
An attacker can leverage the CRLF injection to inject HTTP Headers in an application in order to defeat security mechanisms such XSS filters or the same-origin-policy. 

www.target.com/%0d%0aHackersHeader:NewHeader

CORS (Cross Origin Resource Sharing) activating headers can be injected & the attacker can use JavaScript to access sensitive resources that are otherwise protected by SOP (Same Origin Policy) which prevents sites from different origins to access each other. 
6. Web Cache poisoning
Web-cache poisoning is a technique due to which an attacker can serve poisoned content by manipulating a web cache. In order to successfully exploit this issue, an attacker would need to poison the vulnerable website’s caching proxy, syndicators, content delivery networks (CDNs) or other caching mechanisms in-between the client and the server. After a successful web cache poisoning, the victim will have no idea about the malicious content being served to them by the cache. The below is an example of how an attacker could potentially exploit a host header injection (using CRLF) by poisoning a web-cache.

For the following Request: 

$ telnet www.target.com 80
Trying x.x.x.x...
Connected to www.target.com.
Escape character is '^]'.
GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1     //or Host
Host: target.com

There would be the following response: 

HTTP/1.1 200 OK

Miscellaneous Use Cases: 

1. Injecting a fake HTTP response header: 

Content-Length: 10

Now, the web browser will only parse the next 10 bytes. 
2. Injecting a fake HTTP response header: 

Content-Length: 0

This is treated as a terminated response & the web browsers begin parsing a new response.

Mitigations:

A developer should keep the following things in mind to prevent CRLF injection:

• Sanitization of user input.
• Encode CR & LF characters (\r, \n) so that even when they’re supplied, they aren’t recognized by the server.
• Validate the user input before they reach the response headers (e.g. by using methods like StringEscapeUtils.escapeJava()).
• An unnecessary header should be disabled.
  The following table emphasizes the severity of CRLF injection according to various industry standards: