With blogs or articles like this one, readers are aided by punctuation marks. For example, periods tell readers where a sentence ends, while commas either separate articles in lists or insert hard pauses to help separate ideas. With a well-written blog (like this one), the punctuation is almost invisible, just part of the standard background code that we all learned to process many years ago.

But what happens if a hacker gets into this article and inserts weird punctuation marks in the wrong places? Like this:

Without,even! changing. the, text. it? can. make it! much? harder. to? process! the, information!

That is basically what happens with a CRLF injection attack. The CRLF letters stand for Carriage Return and Line Feed, which are used individually or together to note the termination of a line. If an attacker can insert a CR or LF code into an existing application, they can sometimes change its behavior. The effects are less easy to predict compared with most attacks, but can be no less dangerous to the target organization.

In this episode we will learn:

• How attackers can trigger a CRLF injection
• Why CRLF injections are dangerous
• Techniques that can fix this vulnerability.

How do Attackers Trigger a CRLF Injection?

Injecting CRLF characters into existing code and trying to produce a specific result is rather difficult, though not impossible. It's made harder because an attacker would need to use different CRLF combinations depending on the operating system and other factors of the targeted system. For example, modern Windows machines require both a CR and LF to end a line, while over on Linux, only the LF code is needed. HTTP requests always require a precise CRLF code to end a line.

But beyond the fact that CRLF attacks are difficult to implement, and even harder to predict their results, they are initiated in much the same way as other injection type attacks. A malicious user simply enters data into any area on a website or application that allows it, only they enter the CRLF code instead of, or after, normal input data.

For example, an attacker could enter the ASCII code representing a carriage return (%0d) followed by ASCII for a line feed (%0a) at the end of an HTTPS header. The whole query would then look like this:

https://validsite.com/index.php?page=home%0d%0a

If the data is not sanitized or filtered, the above code might allow some strange things to happen on the target application or website.

Why are CRLF Injections Dangerous?

While CRLF injection attacks are less precise than most, they can be fairly dangerous at least some of the time. At the low end, adding an extra line can mess up log files, which might trigger automatic cybersecurity defenses to alert administrators to a non-issue. However, this could be used to divert resources away from an actual incursion occurring at the same time.

But CRLF attacks can also be directly damaging. For example, if an application is designed to accept commands and then search for a specific file, adding a CRLF code to the query might trigger the application to display that process to the screen instead of keeping it hidden, which could provide valuable information for an attacker.

CRLF injections can also be used to create what is called a response splitting attack, where the end of line codes break up a valid response into multiple pieces. That can give hackers control of the header after the CRLF code, which can be used to inject additional code. It can also be used to create an opening where the attacker can fully inject their own code, and likely trigger another form of attack, on any line following the part broken by the CRLF attack.

Eliminating the CRLF Injection Vulnerability

If there is one key message to take away from this series, it's to never, ever trust user input. Most of the vulnerabilities we have covered in this series have involved user input areas in one way or another, and the CRLF injection flaw is no exception.

At any point where a user can enter input, filters must be applied to prevent the injection of unauthorized code that might be misinterpreted by the application or server. For CRLF attacks, locking down HTTP headers is especially important, but you also can't forget GET and POST parameters or even Cookies. One great way to specifically thwart CRLF codes from helping to trigger further injections is to apply HTML encoding to anything and everything sent back to a user's browser.

More Information about CRLF Injections

For further reading, you can take a look at what OWASP says about CRLF injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.