Web Application Security

CRLF Injection Attack

May 28, 2019

7 min read

13,755 Views

What is CRLF?

The term CRLF refers to Carriage Return (ASCII 13, , \r) Line Feed (ASCII 10, , \n). Carriage Return means the end of a line, and Line Feed refers to the new line. In more simple words, both of these are used to note the end of a line.

Whenever a user sends a request to a web server, the web server replies back with the response that contains both the HTTP headers and the actual website contents. The website contents are separated by a specific combination of special characters, that is carriage return and line feed simply known as the CRLF. The server knows, when a new header begins and ends with CRLF. This tells a web application or user where a new line begins, whether in a file, or in a text block.

These vary depending upon the operating systems:

In Windows, both a CR and LF are required to note the termination of a line whereas in Linux/UNIX, a LF is only required.

In the HTTP protocol, the CR-LF sequence is always used to terminate a line.

What is a CRLF injection vulnerability?

CRLF injection is carried out by an attacker by just simply inserting the carriage return line feed in the user input area to deceive the server or a web application, thus making them to think that an object is terminated and another new object has been started.

Reasons for CRLF injection:

This vulnerability arises very commonly in the HTTP request of web application that accepts the user supplied input from an untrusted source, without being properly validated for malicious character (CRLF).

Impacts of CRLF injection:

The impacts of CRLF injection varies and the risk depends upon the type of scenarios. CRLF Injection allows an attacker to inject client-side malicious scripts (E.g. Cross site scripting) to disclose information. An attacker can gain sensitive information like CSRF token and allow the attacker to set fake cookies. CRLF Injection enables an attacker to deactivate and bypass certain security restrictions like XSS filters and Same Origin Policy (SOP) in the victim’s browsers, making them susceptible to further malicious attacks as below:

Malicious Script Injection
Phishing Attacks
HTTP Header Injection
Client web browser cache poisoning
Client side session hijacking

Scenarios of CRLF injection:

Let’s see some scenarios of CRLF injection

Scenario 1: Client-Side Cookie Injection:

In this scenario, we can set a fake cookie value in to the application, which often leads to client-side cookie injection vulnerability.

Scenario 2: HTTP Header Injection:

In this scenario, we can set a new header value in the URL Parameter with some injected CRLF characters.

Here, (E.g. My_Header:New_Header_Value) we injected the header in the GET parameter of the request.

The server responds to the tampered request without restricting it, and prints the injected header in the server response. New Header is added like Pragma, Cache-Control, Last-Modified, and it may lead to cache poisoning attacks.

Scenario 3: In this scenario, we can probably inject and execute a malicious script in a redirection request combined with CRLF characters to bypass the filter and redirect the user to a malicious crafted website. Also, we’ll be able to run the malicious client-side javascript.

Here, we’ve injected the?Redir.php?c= parameter and through this, we would be able to inject a malicious URL (E.g. url=xssposed.org CRLF INJECTION XSS OPEN REDIRECT) followed with a malicious client side javascript (E.g. ).

The response shows that the original site gets redirected to the crafted fake website and alongside this, the injected malicious client-side JavaScript also gets processed by the server without validation and gets executed as shown in the above response.

Mitigations:

Effectively sanitize and validate the user supplied inputs.
Don’t let the supplied data by the user, directly reach into the response headers without validation. (E.g. StringEscapeUtils.escapeJava())
Use Functions that encodes the CR and LF special characters.
Encode the output in HTTP headers that are publicly visible to the users. Encoding prevents from getting affected by CRLF injection.

What Is HTTP Response Splitting?

An attacker can try to inject CRLF characters into the header and body of an HTTP response since they are separated by CRLF characters. The browser will know that the header ends and the body begins when you use CRLF.

This could lead to cross-site scripting (XSS) vulnerability since an attacker could add data into the response body where the HTML code is transmitted.

Eg: HTTP response splitting leading to XSS

Scenario 4:

Imagine an application that sets a custom header, for example:

Create a fake HTTP response header:0. Content-Length: As a result, the web browser treats this as a terminated answer and starts parsing a new one.
Add another fake HTTP response header: Content-Type: text/html. This is needed for the web browser to properly parse the content.
Add page content with an XSS:

Conclusion:

Application developers should take excessive care and think in the mindset of a hacker. This will help them to create a secure application. In the Application security aspect, the user supplied input should not be trustable and it must be validated properly before accepting it into the application. We must possess good development practices coupled with security methodologies to preserve ourselves from worldly threats.

How Briskinfosec helps you?

Briskinfosec provides top notch web application security assessments and assesses the entire attack surfaces. Pertaining to this, we vigorously validate the user inputs and if any malicious or strange inputs are discovered, we block them. We completely encode the output in HTTP headers, blinding those to the eyes of intruders. Further, we also provide practical awareness on all possible web application issues.

Curious to read our case studies?

Our stakeholder, one of the unique HR solution providers, wanted us to perform an effective security assessment on their web applications. While doing security assessment on their entire web applications, we were able to identify many vulnerabilities including CRLF, then eliminated them, and strengthened their security environment. Check out our case study to know it fully.

Last but not the least:

There are always two ways or more than that to procure many things that we want. For example, to travel towards a place, it can be done through bare foot while the other, through online vehicle booking. To book a movie ticket, it can be done through reaching the spot and then booking while the other can be done through online booking. In both these cases, the former is tiresome while the latter is awesome as the latter saves time and is the easier way to get the job done.

Similarly, Briskinfosec creates Threatsploit Adversary report on a monthly basis. It’s a report that contains the occurrence of global cyberattacks, its causes, its impacts and much more. Instead of looking in search engines and websites about the worldwide cyber breaches and others, just a single click on our report is enough. It will enamor you!

You may be interested on:

Cyber Security Products Vs Cyber Security Services

Getting Started with Frida

Are you still fighting against decade old application attacks?

Web Application Security Website Security Information Security

Written by

Arulselvar Thomas Founder & Director

Cybersecurity expert at Briskinfosec Technology and Consulting, specializing in security assessments, compliance, and helping organizations build resilient security postures.