Web ApplicationJuly 19, 2023Understanding CRLF Injection Attacks: An In-depth Analysis

In web security, CRLF Injection Attacks remain a potent threat. This blog aims to provide comprehensive insight into this malicious technique, its implications, and the preventive measures available to tackle it.

Deciphering CRLF Injection Attacks

Acronymized as CRLF, Carriage Return Line Feed signifies the end of a line (Carriage Return – \r) and a new line (Line Feed – \n). These characters, encoded as ASCII 13 and 10, respectively, are crucial in operating systems like Windows and Internet protocols, including HTTP.

When a user fetches content from a website, the server returns the requested data with HTTP headers. A specific combination of CR and LF marks the separation between headers and content. Therefore, an attacker can exploit a CRLF Injection Attack vulnerability by inserting these characters within an input field, deceiving the server into considering an object terminated and initiating a new one.

Critical Use Cases of CRLF Attacks

The malevolent use of CRLF Injection Attacks typically manifests in two significant ways:

  • Log Poisoning: Here, an attacker introduces an end-of-line character followed by an extra line to manipulate log file entries. This tactic can cloak other attacks or mislead system administrators.
  • HTTP Response Splitting: This method uses CRLF injection to append HTTP headers to the HTTP response, potentially leading to an XSS attack that results in information disclosure.

The Consequences of CRLF Attacks

The repercussions of CRLF Injection Attacks extend beyond the initial deception. These attacks can enable various malicious activities, from setting up fraudulent cookies to stealing CSRF tokens. In addition, they can inject scripts to disclose user data (XSS) and launch various other attacks.

CRLF Injection Attacks also stand as a threat to security measures, including XSS filters and the Same Origin Policy (SOP), making them vulnerable to attacks such as:

→ Cross-Site Scripting (XSS)

XSS is a security vulnerability that allows attackers to inject malicious JavaScript code into the web application. CRLF Injection Attacks can be chained with XSS to execute different malicious attempts.

→ Cookie Injection

In this case, HTTP Response Splitting allows attackers to set malicious cookies on the victim’s browser.

→ Phishing Attacks

An attacker can set the Location header, redirecting the victim to a malicious website that mimics the target website. When the victim enters their credentials, they are sent to the attacker.

→ Session Fixation

The attacker sets a user’s session id to a specific value. This link is sent to the victim, and when the victim logs in using this session, the attacker also logs in using the same session id.

→ HTTP Header Injection

Using CRLF injection, an attacker can inject HTTP Headers into an application to bypass security mechanisms such as XSS filters or the same-origin policy.

→ Web Cache Poisoning

In this technique, an attacker manipulates a web cache to serve poisoned content. After a successful web cache poisoning, the victim remains oblivious to the malicious content being served by the cache.

CRLF Injection: Examples and Use Cases

CRLF Injection Attacks can be executed in various ways. Here are a few examples:

  • Injecting a Fake HTTP Response Header: Here, an attacker can manipulate the ‘Content-Length’ header to control the portion of the response parsed by the web browser.
  • Injecting a Fake HTTP Response: In this case, an attacker can forge a fake HTTP response header, making the web browser parse a new response.

CRLF Practical 

For this blog practical, we will be using PortSwigger lab – https://portswigger.net/web-security/request-smuggling/advanced/lab-request-smuggling-h2-request-splitting-via-crlf-injection 

Challenge Objective: Exploit HTTP/2 Request Splitting vulnerability via CRLF injection to poison the response queue and gain unauthorized access to the admin panel (/admin). The ultimate goal is to delete the user ‘carlos’ using the captured admin session cookie.

Lab: HTTP/2 request splitting via CRLF injection 

Figure 1: PortSwigger Labs

We will start by intercepting a GET request and sending it to Burp’s repeater. 

Figure 2: GET request

Expand the Inspector’s Request Attributes section and ensure the protocol is set to HTTP/2. 

Figure 3: Expand the Inspector’s Request Attributes section

Modify the request path to an endpoint that does not exist (e.g., /x) to force the server to return a 404 response code. 

Figure 4: Modify the request

Inject a specially crafted header into the request, exploiting CRLF (Carriage Return Line Feed) injection to split the request into two parts. This technique aims to smuggle another request to a non-existent endpoint.

The injected header should include the following content:

    • Name: foo
    • Value: bar\r\n \r\n GET /x HTTP/1.1\r\n Host: YOUR-LAB-ID.web-security-academy.net
Figure 5: Adding new header

Proceed to send the modified request to the server, thus initiating the response queue poisoning process. After sending the request, wait approximately 5 seconds to allow time for the server to process the request and respond. If you receive a response with a different status code (not 404), it indicates a successful capture of another user’s response. Continue repeating the process (steps 7 to 10) until you capture a response with a 302 status code containing the admin’s new post-login session cookie. This signifies that you have successfully accessed the admin user’s privileges.

Figure 6: 302 response containing stolen session cookie

Copy the stolen session cookie from the captured 302 response, as it will be required for further steps. Utilize the stolen session cookie to craft a new request to access the admin panel, add /admin at the end of the URL, and capture the request in Burp

Figure 7: Requesting Admin panel


Figure 8: Captured Admin panel request

Repeatedly send the crafted request (step 13) until you receive a 200 response code, indicating that you have successfully accessed the admin panel. 

Figure 9: Successfully accessing the Admin panel

Within the admin panel’s response, click on delete to deletecarlos. Capture the request and change the session cookie to the stolen session cookie 

Figure 10: Capture the delete request in Burp Suite

Send the request to delete ‘carlos‘, completing the lab successfully. 

Figure 11: Send request to delete ‘carlos’

Safeguarding Against CRLF Injection Attacks

To prevent CRLF Injection Attacks, developers need to consider the following:

  • Sanitize User Input: This is the first step towards securing your application. Ensure the user input is sanitized to remove potentially harmful characters or sequences, including CR and LF characters.
  • Validate User Input: Before the user input reaches the response headers, validate it to avoid harmful injections.
  • Disable Unnecessary Headers: Headers that are not required should be disabled to prevent them from being exploited.

By implementing these practices, developers can significantly reduce the risk of CRLF Injection Attacks.

The Severity of CRLF Injection Attacks

The OWASP Top 10 2021 includes a new category called “Injection”, which encompasses a variety of injection attacks, including CRLF injection. This change reflects the growing threat posed by injection attacks and the importance of taking steps to protect against them. They can be leveraged to escalate to more severe attacks that exploit other web application vulnerabilities. Hence, they demand serious attention.

Tools to Detect and Mitigate CRLF Injections

By conducting regular pen tests, you can help ensure that your web applications are secure and not vulnerable to attacks such as CRLF injection.

CRLF (Carriage Return Line Feed) injection is a type of web application security vulnerability that occurs when an attacker injects special characters like “%0D” (Carriage Return) and “%0A” (Line Feed) into input fields or HTTP headers. This can lead to attacks such as HTTP response splitting, HTTP header injection, and cross-site scripting (XSS). You can use a combination of manual code reviews and automated security testing tools to detect and mitigate CRLF injections. Here are some tools and techniques you can use:

→ Manual Code Reviews

Conducting manual code reviews allows you to inspect the application’s source code and configuration files to identify potential CRLF injection vulnerabilities. Look for places where your application uses user-supplied input to construct HTTP responses, HTTP headers, or logs, and ensure that you implement proper input validation, sanitization, and output encoding.

→ Static Application Security Testing (SAST) Tools

SAST tools can automatically analyze source code to identify security vulnerabilities, including CRLF injections. These tools can help you spot potential issues in the codebase before the application is deployed.

→ Dynamic Application Security Testing (DAST) Tools

DAST tools simulate real-world attacks against your running web application to identify vulnerabilities, including CRLF injections, from an attacker’s perspective. They send specially crafted requests to the application and analyze the responses for potential issues.

→ Web Application Firewalls (WAFs)

Implementing a WAF can help protect your web application from CRLF injection attacks. A WAF filters and monitors HTTP requests and responses, blocking malicious inputs that contain CRLF characters before they reach the application.

→ Proper Input Validation and Output Encoding

Ensuring that user-supplied input is properly validated and sanitized before being used to construct HTTP responses or headers is crucial. Additionally, use proper output encoding to prevent unintended interpretation of user input.

→ Stay Informed about Security Updates

Keep your software and libraries updated to avoid known vulnerabilities, as developers frequently release patches to address security issues.

Remember that no single tool or approach is foolproof, so adopting a layered security strategy and conducting regular security assessments is essential to identify and mitigate CRLF injection vulnerabilities effectively.

How to Prevent CRLF Injections

Here are the steps to prevent CRLF Injection Attacks:

  • Don’t Trust User Input: Revise your code to ensure that content supplied by the user is never used directly in the HTTP stream.
  • Strip Newlines: Remove newline characters before passing content into the HTTP header.
  • Encode Data: Encode the data you pass into HTTP headers. This will effectively scramble the CR and LF codes if the attacker attempts to inject them.
  • Conduct Regular Pen tests: By performing regular penetration testing on your web applications and promptly addressing any vulnerabilities, you can significantly reduce the risk of these attacks.

In conclusion, CRLF Injection Attacks may seem limited in impact. However, they can serve as a stepping stone to more severe attacks. By understanding the nature of these attacks and implementing robust defenses, we can significantly reduce their threat. This, in turn, will ensure a safer web environment.

Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you want to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.

“Join us on our journey of growth and development by signing up for our comprehensive courses.

Gaurav Patil

by Gaurav Patil

Associate Security Consultant | Redfox Security