A CRLF is about as simple as vulnerabilities get! CRLF stands for Carriage Return Line Feed, which is a term applied to new-line characters. The attack involves injecting new-line characters in user-submitted data.
Very often web information is sent/received/stored in line-delimited format. For example:
CRLF and Email
Server-side code must be careful when generating output in line-delimited format. For example, if your server-side code sets cookies or sends emails based on user-submitted data, it is possible that the data contains new-lines. For example, if the string:
...is used as the Subject in an email, an attacker could cause your server to send spam.
Or, maybe your website allows visitors to order t-shirts online. Every time someone orders a t-shirt, a little PHP script sends you an email. A malicious user could get your script to send him a copy of the order, which might include sensitive information. Worse, if a hacker knows what these order emails look like, he could then forge orders and maybe get free t-shirts.
Cleverly formed URLs can also cause problems if the web server or browser doesn't remove new-lines. For example, the following URL can be typed into a browser and sent to a vulnerable web server:
The web server might interpret it like this:
...which means a seemingly harmless link (in an email or forum, for example) could change the cookies seen by the server. Likewise, a server which echoes back cookies may be tricked into sending extra cookies. For example, if your server is implemented like this:
... then a client could send you a cookie with the value "blah \nCookie: loggedin=true".
Using safe libraries will help mitigate this problem. For example, the PHP setcookie function URL-encodes the cookie value. However, it is still possible to set HTML headers, email headers, etc manually through PHP or any other server-side language.
Very often a web server will be configured to log all traffic for various reasons. Some companies are required to log access and may be subpoenaed for them. By sending a CRLF-injected GET request to a vulnerability web server, it may be possible to add fake entries to the access log (or any other log-like file):
This might cause the following two log entries:
While seemingly harmless, keep in mind that access logs have been used in criminal court as evidence.