Web applications across the digital world are teeming with vulnerabilities increasingly equipped to defeat security mechanisms. Among them are injection attacks. We are aware of the many injection vulnerabilities present in a web application, for example, SQL injection, HTML injection, CRLF injection, cross-site scripting and many others. This article will discuss CRLF injection vulnerability in detail for web application security. Let’s dive into the nitty-gritties of CRLF, starting with its definition.

What is CRLF?

Carriage Return

The term CRLF refers to carriage return line feed. Carriage return is denoted by ASCII 13 (r), indicating the end of a line. We place ‘r‘ to represent the end of a line.

Line Feed

Line feed is denoted by ASCII 10 (n), indicating the place where a new line begins. Whenever we have to start a new line, we place ‘n‘. Anything written after ‘n’ will come in a new line. The ‘n’ and ‘r’ (cr and lf) are called CRLF characters.

CRLF – Defined

Whenever a user performs anything on the internet, the web browser sends some requests to the web server. The web server answers the browser with an HTTP response regarding that request. The HTTP response received has some HTTP header and the actual website content. The special CRLF characters enter the scene here, separating the headers and the actual website content in the HTTP response. Carriage return line feed not only demarcates the position where a new HTTP header begins or ends but also tells the user where a line starts or ends even in a file or in a block of text.

These CRLF characters are also used by the operating systems. Windows uses both CR and LF for line termination, while UNIX/Linux only uses LF. HTTP protocol also uses the CRLF character sequence for line termination.

What is CRLF injection vulnerability?

The attacker attacks the web application by inserting carriage and linefeed (cr and lf) via the user input area. The CRLF injection attack dupes the web server or the web application into thinking that the first object given has terminated and another object has started running. CRLF characters are not intended to be malicious because they are originally used to separate the HTTP or HTTPS headers and actual web content. However, they can still be used as payloads for malicious attacks.

The main reason behind the CRLF injection attack is accepting unsanitised input from the user before validating that from a trusted source.

CRLF Injection In Web Application

For a web application, CRLF injection is rated as P3 severity in bugcrowd. CRLF injection can further be escalated from information disclosure to Remote Code Execution. It can also lead to cross-site scripting attacks, web cache poisoning and much more.

HTTP Response Splitting

As previously seen, the HTTP protocol not only uses CRLF to distinguish where a header begins and ceases to exist but also separates the HTTP headers and the actual content.

Now let’s see how attackers add HTTP headers using CRLF injections in HTTP response splitting. Actually, for CRLF injection attacker inserts %0d and %0a, which are URL encoding forms of cr and lf.

In HTTP response splitting, the attacker inserts double CRLF to terminate the HTTP header, and he can add content between the HTTP headers and actual content. That content can be javascript code and can lead to XSS.

HTTP response splitting leading to XSS

Suppose there is an HTTP header present in a web application.

Example

X-Header-Value: XYZ

Let us assume that the header value can be set via the GET method. Now assume that there is no URL encoding present. It means whatever we put in will be reflected in the HTTP header. The attacker can use a double CRLF injection to terminate the HTTP header and insert anything after that. See this using the previous example.

?Value=XYZ%0d%0a%0d%0a

Here the XSS payload will get executed and open an alert window showing the domain. The attacker can also use a different XSS payload to increase the impact.

HTTP Header Injection

The exploitation of CRLF injection can lead to HTTP header injection vulnerabilities. This can make attackers insert or set an HTTP custom header of their own to bypass certain security restrictions like the browser’s XSS filters or the same-origin policy. Attackers can also extract sensitive data like CSRF tokens and also set their own cookies. This way, attackers can defeat the security mechanisms of web applications.

If the attacker can inject HTTP headers like the ‘Access-Control-Allow-Origin’ header, he can activate cross-origin resource sharing and get the javascript codes protected by the same-origin policy.

Now let’s see how we can insert HTTP headers into the HTTP response headers. We can add a fake HTTP response header into the URL parameter with the %0d %0a character. We will be using a single CRLF to insert a fake HTTP response header. We will modify the HTTP request as shown below:-

Example

GET /%0d%0aMy-Header: Header

If the web applications are vulnerable to CRLF injection vulnerability, then the header will reflect into the response headers as well as the other headers.

What are the impacts of CRLF injection vulnerabilities?

The impacts of CRLF injection vulnerabilities can lead to several attacks ranging from information disclosure, HTTP header injection to cross-site scripting and remote code execution. By further exploiting the CRLF injections, one can bypass the security restrictions like the browser’s XSS filter and the same-origin policy. The attacker can befool the victim’s browser into revealing sensitive information. Web cache poisoning, website defacement, hijacking the user’s session are some of the other implications.

Note

CRLF injection is not in the list of OWASP Top 10, but it is really impactful and can cause serious damage to the application.

Ways To Prevent CRLF Injections

In order to prevent CRLF injections, user input should be properly sanitised. User input must be URL encoded, especially the CRLF character. We should also use a firewall for web application security. We should also keep the programming languages and the libraries updated to prevent cr and lf characters from being injected. Encode output header properly so that any malicious headers would not be visible to the user. We should also keep the unwanted or unnecessary headers disabled.

Note:- Never trust the input data.

Summary

CRLF injection is an attack where the attacker inserts carriage and linefeed via input area. Manipulating the HTTP request and playing with 0d 0a characters can further escalate this injection into high severity vulnerabilities like XSS, remote code executing, user’s session hijacking, web cache poisoning, header injection, sensitive information disclosure and much more. It is a critical vulnerability not to be taken lightly.

It happens because unsanitised input given by the user gets accepted by the browser and sent to the server. The attacker can craft their very own malicious input and harm the application according to their own benefits and needs.

One can also use this attack for redirecting users to some malicious site or phishing. It can also allow web security to fall through for web applications like XSS filters bypass, activating cross-origin resource sharing letting attackers access javascript codes protected by the same-origin policy.

With this article, we have attempted to shed light on some of the effective ways by which we can prevent CRLF injections. We should check whether the input supplied is properly sanitised or not. The unnecessary headers must be disabled, and input entered by the user needs to be correctly URL encoded. We can also use a firewall to prevent CRLF and other attacks.

Head to our site to better equip your system administrators with different aspects of web security and internet protocols and shield your organisation from falling prey to web attacks.