A CRLF Injection (Carriage Return Line Feed Injection) attack is a type of security vulnerability that occurs when an attacker is able to inject malicious CR (Carriage Return, \r
) and LF (Line Feed, \n
) characters into an application's output. These characters are used to terminate lines and create new ones, and in the context of web applications, they can be exploited in various ways.
How CRLF Injection Works:
- CR (Carriage Return) is represented by the character
\r
. - LF (Line Feed) is represented by the character
\n
.
When these characters are inserted into a web application's output, they can change the way data is interpreted by the browser, server, or other parts of the application. This injection allows an attacker to manipulate the format of the output or cause unintended behavior.
Common Use Cases for CRLF Injection:
-
HTTP Response Splitting:
- This is one of the most common types of CRLF injection attacks.
- In this attack, the attacker injects a CRLF sequence into an HTTP response header. The result is that the injected CRLF ends the current header and starts a new one, which the server interprets as separate headers.
- This can lead to several vulnerabilities, including:
- HTTP Response Splitting: The attacker can inject headers like
Set-Cookie
orLocation
and perform actions like session fixation, redirecting the user to a malicious site, or injecting cookies. - Cache Poisoning: By altering headers, attackers can inject malicious content into a shared cache, causing future users to receive this malicious content.
- HTTP Response Splitting: The attacker can inject headers like
-
XSS (Cross-Site Scripting) Attacks:
- CRLF injection can also be used to facilitate cross-site scripting (XSS) attacks. By injecting CRLF characters into a web page’s output, an attacker could split the response and inject JavaScript code into a response header or body.
- This could lead to the execution of malicious scripts in a user's browser.
-
Log Injection:
- Attackers can inject CRLF characters into logs (especially HTTP logs) to manipulate or confuse log readers. This could hide malicious activities, create misleading log entries, or inject additional unwanted log entries.
-
Email Header Injection:
- If an application constructs email headers (such as
To
,Subject
, orFrom
) by concatenating user input directly, CRLF injection could be used to add additional headers to the email. - This could lead to the delivery of spam, phishing attacks, or data leaks.
- If an application constructs email headers (such as
Example of CRLF Injection in HTTP Response Splitting:
Imagine a web application that takes user input to generate a dynamic HTTP response. Suppose the application builds an HTTP header like this:
If the attacker inputs something like this:
The resulting response could look like:
This splits the response into multiple headers and can set a new malicious cookie (sessionId=maliciousSessionId
), potentially hijacking the user's session.
Prevention of CRLF Injection:
-
Input Validation and Sanitization:
- Always sanitize user inputs. Remove or encode any
\r
and\n
characters that may be injected into HTTP headers, URLs, or other output locations.
- Always sanitize user inputs. Remove or encode any
-
Use Proper Output Encoding:
- When injecting user input into HTTP headers or web pages, ensure that the data is properly encoded (e.g., URL encoding for HTTP headers) to prevent injection.
-
Use Frameworks that Handle HTTP Headers Properly:
- Many modern web frameworks handle headers and other user inputs safely, ensuring that malicious characters are not injected into headers.
-
Avoid Constructing Headers Manually:
- Do not concatenate user inputs directly to HTTP headers. Instead, use appropriate functions or libraries that handle header construction and ensure that user inputs are sanitized.
-
Test for Vulnerabilities:
- Regularly test web applications for CRLF injection vulnerabilities using tools like Burp Suite or OWASP ZAP.