Carriage Return and Line Feed (CRLF) are special character elements typically embedded in Hypertext Transfer Protocol (HTTP) headers and some other software code. The inclusion of these character elements is to denote an End of Line (EOL) marker. These character elements are actually very common as many protocols of the Internet Protocol (IP) Suite, such as HTTP, MIME, and NNTP, use them to discretely split the text into elements. As such, CRLF injection is when an attacker can inject a sequence of CRLF into one of these protocols or software applications; such as an HTTP stream. This is one of the attacks most common uses and as such, has the alternative names of HTTP Response Splitting and Neutralization of CRLF Sequences in HTTP Headers.

Effects on Hypertext Transfer Protocol Headers

As mentioned before, when the technique is used on an HTTP Response header, it can also be referred to as HTTP Response Splitting. This process can occur from input that was not properly sanitized or incorrectly neutralized. This is carried out by an attacker utilizing a specifically crafted text stream with CLRF characters injected in it which can cause problems ranging from medium to high severity. These injected CRLF characters split the text and allow the attacker to embed text sequences the web browser would not be expecting. This can lead to the attacker modifying application data, compromising data integrity, and even enable the exploitation of further vulnerabilities such as cross-site scripting (XSS), website defacement, proxy and web server cache poisoning, client session hijacking, and more.

Solutions and Prevention Measures

Despite CRLF injects can be quite harmful and severe, they are actually very easy to circumvent. The most common rule any developer and network administrator should employ is to never trust a user’s input. This rule will develop the habit and practice for developers and network administrators to always sanitize user input and prevent not only CRLF injections but countless other security vulnerabilities at the application layer as well. This practice will encourage good development practices such as encoding output in HTTP headers which is the best method for handling the issue.