Understanding CRLF Injection: A Web Application Vulnerability and Mitigation

CRLF (Carriage Return Line Feed) injection is a web application vulnerability that occurs when an attacker can inject malicious CRLF characters into an HTTP response. This vulnerability can lead to various security issues, such as HTTP header injection, HTTP response splitting, session fixation, cross-site scripting (XSS), and cache poisoning.

 

Understanding the CRLF Injection

To understand CRLF injection, let’s break down the term:

Carriage Return (CR): It is a control character (ASCII code 13) that instructs the cursor to return to the beginning of the current line.

Line Feed (LF): It is a control character (ASCII code 10) that instructs the cursor to move to the next line.

In the context of HTTP, CRLF refers to the sequence of both CR and LF characters (“\r\n”). These characters are used to separate lines in the HTTP protocol.

The CRLF injection vulnerability arises when user-controlled data (input) is not properly sanitized or validated before being used in constructing an HTTP response. Attackers exploit this vulnerability by injecting CRLF characters into user input with the aim of manipulating the HTTP response.

 

Entry Points for CRLF Injection

1. Identify all parameters where user input is involved.
2. For each parameter, determine if the data is passed to the HTTP response headers.

•    Identify the response headers that are influenced by user input.
•    Verify if the user input value is directly or indirectly included in the response headers.

3. If the user input value is indeed passed to the response headers, perform CRLF injection testing.

•    Craft specific input values containing CRLF characters to test for potential injection points.
•    Observe if the injected CRLF characters cause any unexpected behavior in the response headers.
•    Check if the injected CRLF characters can be used to perform HTTP response splitting, cache poisoning, session fixation, or other related attacks.

 

Advanced Chain Vulnerabilities

CRLF injection can be used as part of a chain of vulnerabilities to exploit various security issues. Here are a few common chain vulnerabilities that can be leveraged alongside CRLF injection:

• HTTP Response Splitting:

CRLF injection can be combined with other vulnerabilities, such as inadequate input validation or insecure concatenation of user input, to perform HTTP response splitting attacks. By injecting CRLF characters, an attacker can manipulate the response headers and potentially split the response into multiple parts, leading to various security issues like cache poisoning, session fixation, or cross-site scripting (XSS).

Example:

Let’s consider a different example where the code segment reads a user’s email address from an HTTP request and sets it as a cookie header in an HTTP response:

In this example, the application takes the email address submitted in the request and sets it as a cookie named “user_email” in the HTTP response.

Suppose the email address “john.doe@example.com” is submitted in the request. The HTTP response including this cookie might look like this:

This response maintains its intended form because the input (“john.doe@example.com”) is a valid email address with no harmful characters.

Now, let’s consider what happens if an attacker submits a malicious email address containing CRLF characters:

The value for the “email” parameter is “john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a”. When the application processes this input and sets the cookie, the HTTP response could be manipulated as follows

In this case, the attacker injected CRLF characters (“%0d%0a”) in the email parameter, which led to the insertion of an additional “Set-Cookie” header in the response. The attacker has effectively set another cookie named “admin” with the value “true”. This could be used for privilege escalation or other security-related attacks.

 

• Cross-Site Scripting (XSS):

  CRLF injection can be used as a stepping stone for cross-site scripting attacks. By injecting CRLF characters to manipulate the response, an attacker may introduce malicious scripts that can be executed in the context of other users, leading to session hijacking, data theft, or other forms of unauthorized access.

Example:

Let Create a payload to Escalate CRLF to Cross Site Scripting (XSS):

• First break the line and add Content-Type: text/html header if the response it not in text

• We now require empty lines following Content-Type; we obtain these by adding feed return (%0a) then add malicious HTML payload, and we need to make comment for the remaining lines by adding HTML Comment. 

Detection and Exploitation

While performing a VAPT (Vulnerability Assessment and Penetration Testing) on a web application, I discovered a potential CRLF (Carriage Return Line Feed) vulnerability. Please find the explanation for the Detection and exploitation of CRLF Vulnerability with proof of concept:

• During the assessment, it is observed that the authentication mechanism of the web application carried in two ways:
  • Authentication using a jsessionid in the cookies.
  • Authentication using the jsessionid appended at the end of the URL (e.g., https://domain.name/endpoint;jsessionid=xxxxxxxxxxx) – this method help to attack the surface remotely.

• It is noticed that the jsessionid value was being reflected in the response. By appending a random string at the end of the jsessionid value to see if it would also be reflected.
• By adding the random string, it was reflected in the response, indicating that the jsessionid value was being used to construct the response headers.
• To validate the CRLF vulnerability, let injects a basic payload that included CRLF characters to split the response header. This resulted in the response being split into a new line.
• However, the response had a status code of 302 and a Location header. To ensure a successful attack, make sure to comment out any unnecessary headers from the response.
• To escalate the attack, used XSS via CRLF payload which contains the “Content-Type: text/html” header, followed by a blank line, and then injecting an XSS payload (<img src=c onerror=alert(“XSS”)). Finally, add a HTML comment start tag (<!–).

 

By adding comment, all the unnecessary headers and content comes under comment.  HTML comment is used because response is having Content-Type:text/html header.

Payload: (XSS via CRLF)

 

Pic 1: Request and Response of Malicious URL

 

Pic 2: By opening the malicious URL on user browser, JavaScript is executed successfully.

 

The basic flow to check for CRLF Injection in any web application is as follows:

1. Inject CRLF payloads at the end of the URL or inject CRLF payload to any known parameters.
2. Send the modified request and capture the response.
3. Check the response headers to identify any anomalies or unexpected behavior.
4. Look for unexpected line breaks or new lines in the response headers.
5. Validate if the injected CRLF characters have affected the headers.
6. Check for signs of HTTP response splitting or other related vulnerabilities.

 

The above process can be automated using the nuclei template described below

Automation: Nuclei Template to validate basic CRLF checks:

 

Payloads:

• “Carriage Return” (\r) is a control character that moves the cursor or print head back to the beginning of the line.
• “Line Feed” (\n) is a control character that moves the cursor or print head down to the next line.
• “%0d%0a” (URL encoding):

%0d corresponds to the ASCII hexadecimal representation of Carriage Return (CR) character (decimal 13).

%0a corresponds to the ASCII hexadecimal representation of Line Feed (LF) character (decimal 10).

In URL encoding, characters that are not safe for use in a URL are replaced with a “%” followed by their ASCII hexadecimal representation. This is commonly used when sending data in URLs or as part of query parameters.

 

• “\r\n” (Escape sequences in programming languages):

\r represents the Carriage Return (CR) character.

\n represents the Line Feed (LF) character.

In many programming languages, escape sequences are used to represent special characters that cannot be easily typed or printed directly. “\r” and “\n” are escape sequences used to represent the CR and LF characters, respectively. These escape sequences are commonly used in string literals within code to specify line breaks or other control characters.

• %00 – Null Bytes
• %20 – empty space

 

Filter Bypass Payloads:

• %E5%98%8A = %0A = \u560a

%E5%98%8A: This is a representation of a character using URL encoding. It corresponds to the UTF-8 encoding of the character 嘊. In UTF-8, 嘊 is represented by the bytes 0xE5 0x98 0x8A.

%0A: This is the representation of the Line Feed (LF) character in URL encoding. In ASCII, LF has the hexadecimal value 0x0A, which corresponds to decimal 10. It represents a new line or line break in text.

\u560a: This is the representation of the character 嘊 using a Unicode escape sequence in programming languages. The Unicode code point of 嘊 is U+560A, and the \u escape sequence is used to represent Unicode characters in a string literal.

 

• %E5%98%8D = %0D = \u560d

 %E5%98%8D: This is another representation of a character using URL encoding. It corresponds to the UTF-8 encoding of the character 嘍. In UTF-8, 嘍 is represented by the bytes 0xE5 0x98 0x8D.

%0D: This is the representation of the Carriage Return (CR) character in URL encoding. In ASCII, CR has the hexadecimal value 0x0D, which corresponds to decimal 13. It represents a carriage return or the cursor moving to the beginning of the line.

\u560d: This is the representation of the character 嘍 using a Unicode escape sequence in programming languages. The Unicode code point of 嘍 is U+560D.

 

Let’s Create a payload to escalate CRLF to Open Redirection:

• First Break the line by using Carriage Return & Line Feed (%0d%0a) and Add Location header with malicious domain to redirect.

 

Mitigation

To prevent CRLF injection vulnerabilities, it is crucial to follow secure coding practices, such as:

• Validate and sanitize user input to prevent the injection of CRLF characters or any other malicious input.
• Properly encode any user-supplied data before including it in HTTP responses to prevent CRLF injection attacks.
• Follow secure coding guidelines and best practices to minimize the risk of vulnerabilities.

 

References:

https://owasp.org/www-community/vulnerabilities/CRLF_Injection

https://book.hacktricks.xyz/pentesting-web/crlf-0d-0a