Web site security–CRLF Injection Attack

The term CRLF stands for Carriage Return (CR, ASCII 13, \r) Line Feed (LF, ASCII 10, \n). These are ACSII characters which display nothing on screen but are very widely used in Windows to indicate an end of line. On Linux/UNIX systems the end of line is indicated by the use of the Line Feed only.

This combination of CR and LR is used for example when pressing “Enter” on the keyboard. Depending on the application being used, pressing “Enter” generally instructs the application to start a new line, or to send a command.

A CRLF Injection attack occurs when a hacker manages to inject CRLF Commands into the system. This kind of attack is not a technological security hole in the Operating System or server software, but rather it depends on the way that a website is developed. Some developers are unaware of this kind of attack and leave open doors when developing web applications, allowing hackers to inject CRLF Commands.

In some types of websites, this flaw may be lethal to the application’s security. In other cases, this may just be a small bug with minimal priority. It all depends on whether this flaw allows the user to manipulate the web application.

Example of a CRLF Injection Attack

Many network protocols, including HTTP, make extensive use of the Carriage Return and Line Feed combination of commands since each line used in this protocol is separated by a CRLF. If a user is able to define an unfiltered HTTP header, it poses a risk since the user would then be able to communicate directly to the server, bypassing the application layer.

For example E-mail, News (NNTP) and HTTP headers are all based on the structure of “Key: Value” and each line is defined with a CRLF combination at the end. The “Location:” header is used in HTTP to redirect to another URL and a “Set-Cookie:” header is used for cookies. If these inputs are not properly validated, CR and LF characters can be embedded in the user input, and web scripts can be fooled to do other things than what they were originally constructed for.

If the input is not checked for CR and LF and the script constructs a redirect with the string:

Location: $url%0d%0a

We can redirect to a site while setting a cookie by setting $url (as one string) to:

http://www.i-was-redirected.com/%0d%0aSet-Cookie: Authenticated=yes%0d%0aReferer: www.somesite.com

If an attacker can save the URLs that another user will be redirected to, including cookies with important data, this can be serious.
Solution

The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should “remove everything but the known good data” and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server.