CRLF Injection
What is CRLF
Injection?
CRLF Injection attacks are a class of attacks which involve including
new line characters (i.e. carriage return (CR) and line feed (LF)) in user
input with the intention of achieve a malicious aim. It can lead to attacks such
as
Cross-Site Scripting,
HTTP Response Splitting and
Email injection.
What makes a
site vulnerable to the attack?
A site is vulnerable to CRLF injection if it allows users to enter
CR and LF characters in their input. The actual effect of such injections
determines whether the possible attacks are actually significant. The attack
will be significant if the insertion of the characters can be used to achieve
something the user would not normally be allowed to do (add new HTTP headers,
add new email headers, add new log entries, etc.).
Impact of the
attack
The use to which the input is put by the website determines the
effect and severity of the attack. If the attacker injects the new line into
HTTP headers created by the website, he can potentially carry out an XSS attack,
a HTTP Response Splitting attack, or modify the headers to change the way the
user’s browser interprets the page. If the attacker injects the new line into
an email created by the site, he can potentially perform an email injection
attack. The attack can also be used against other aspects of the site. For
instance, CRLF injection may allow additional, attacker-specified entries to be
added to a log file. CRLF is a slightly trickier attack to discover and pull off that its cousin
cross-site scripting. However, as webmasters start to wise up and eliminate cross-site scripting vulnerabilities the balance may begin to tip. The more involved CRLF injection vulnerabilities, while stemming from a similar cause (unvalidated user data being included in a HTTP response), are likely to be missed in many cases and the sites left vulnerable. Once cross-site scripting vulnerabilities begin to dry up there may be a corresponding increase in real world CRLF injection attacks.
Preventing the
attack
To prevent the attack it is necessary, at a minimum, to remove the
CR and LF characters from user input before using that input anywhere which may
be vulnerable to manipulation. It is important to note that there are different
ways in which these characters can be encoded in order to evade such filtering.
While it may be possible to capture all possible encodings, it is generally not
a good idea to base security on the assumption that you have. Instead (as is
usually the case), it is better to define a set of characters for which it is
known that the website will behave correctly, and allow only those characters.
If the user-input contains anything else, it should be rejected or the
offending characters removed prior to use.