Understanding CRLF Injection: A Web Application Vulnerability and Mitigation

Home » Cybersecurity » Application Security » 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.

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.

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:

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 “[email protected]” is submitted in the request. The HTTP response including this cookie might look like this:

This response maintains its intended form because the input (“[email protected]”) 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.

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):

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:

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:

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

Automation: Nuclei Template to validate basic CRLF checks:

%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 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.

Filter Bypass Payloads:

%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: 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:

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

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

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

The post Understanding CRLF Injection: A Web Application Vulnerability and Mitigation appeared first on WeSecureApp :: Simplifying Enterprise Security.

*** This is a Security Bloggers Network syndicated blog from WeSecureApp :: Simplifying Enterprise Security authored by Sekhar Poola. Read the original post at: https://wesecureapp.com/blog/understanding-crlf-injection-a-web-application-vulnerability-and-mitigation/