Web applications throughout the digital world are riddled with vulnerabilities increasingly equipped to defeat security mechanisms. Among them are injection attacks. We are aware of the many injections vulnerabilities present in a web applicationeg SQL injection, HTML injection, CRLF injection, cross-site scripting and many others. This article will discuss the CRLF injection vulnerability in detail for web application security. Let’s dive into the essential details of CRLF, starting with its definition.
What is CRLF?
The term CRLF refers to the carriage return line feed. The carriage return is denoted by ASCII 13 (\r), which indicates the end of a line. We place ‘\r’ to represent the end of a line.
The line break is indicated by ASCII 10 (\n), which indicates the place where a new line begins. Whenever we have to start a new line, we put ‘\n’. Anything written after ‘\n’ will appear on a new line. The characters ‘\n’ and ‘r’ (cr and lf) are called CRLF characters.
CRLF – Defined
Every time a user does something on the Internet, the web browser sends some requests to the web server. The web server responds to the browser with an HTTP response regarding that request. The received HTTP response has an HTTP header and the actual content of the website. Special CRLF characters come into the picture here, separating the headers and the actual content of the website 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 begins or ends, even in a file or block of text.
These CRLF characters are also used by operating systems. Windows uses both CR and LF for line termination, while UNIX/Linux only uses LF. The HTTP protocol also uses the CRLF character sequence for line termination.
What is the CRLF injection vulnerability?
The attacker attacks the web application by inserting carriage and line feed (cr and lf) through the user input area. The CRLF injection attack tricks the web server or web application into thinking that the first supplied object has finished and another object has started executing. CRLF characters are not intended to be malicious because they were originally used to separate HTTP 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 to accept unsanitized user input before validating it from a trusted source.
CRLF injection in web application
For a web application, CRLF injection has a severity of P3 in bugcrowd. CRLF injection can be further scaled from information disclosure to remote code execution. It can also lead to cross-site scripting attacks, web cache poisoning and much more.
HTTP Response Split
As seen above, the HTTP protocol not only uses CRLF to distinguish where a header begins and ends, it also separates HTTP headers and the actual content.
Now let’s see how attackers add HTTP headers using CRLF injections in HTTP Response Split. Actually, for CRLF injection, the attacker inserts %0d and %0a, which are URL encoding forms of cr and lf.
HTTP response splitting leading to XSS
Suppose there is an HTTP header present in a web application.
X header value: XYZ
Suppose the value of the header can be set via the GET method. Now suppose there is no URL encoding present. It means that whatever we input 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 example above.
Here the XSS payload will be executed and an alert window will open showing the domain. The attacker can also use a different XSS payload to increase the impact.
HTTP header injection
Exploitation of CRLF injection can lead to HTTP header injection vulnerabilities. This can lead attackers to insert or set their own custom HTTP header to bypass certain security restrictions, such as browser XSS filters or same-origin policy. Attackers can also mine sensitive data like CSRF tokens and also set their own cookies. In this way, attackers can defeat the security mechanisms of web applications.
Now let’s see how we can insert HTTP headers into HTTP response headers. We can add a fake HTTP response header in the URL parameter with the %0d %0a character. We will use a single CRLF to insert a bogus HTTP response header. We will modify the HTTP request as shown below:
GET /%0d%0aMy-Header: Header
If web applications are vulnerable to the CRLF injection vulnerability, the header will be reflected in response headers as well as other headers.
What are the impacts of CRLF injection vulnerabilities?
The impacts of the CRLF injection vulnerabilities can lead to various attacks ranging from information disclosure, HTTP header injection to cross-site scripting and remote code execution. By further exploiting CRLF injections, security restrictions such as the browser’s XSS filter and same-origin policy can be circumvented. The attacker can trick the victim’s browser into revealing sensitive information. Web cache poisoning, website defacement, user session hijacking are some of the other implications.
CRLF injection is not on the OWASP Top 10 list, but it is really shocking and can cause serious damage to the application.
Ways to prevent CRLF injections
To prevent CRLF injections, user input must be properly sanitized. User input must be URL encoded, especially the CRLF character. We should also use a firewall for web application security. We also need to keep programming languages and libraries up to date to prevent cr and lf characters from being injected. Encode the output header correctly so that the user cannot see the malicious headers. We should also keep unwanted or unnecessary headers disabled.
Note: – Never trust the input data.
CRLF injection is an attack where the attacker inserts a carriage and line feed through the input area. Manipulating the HTTP request and playing around with the 0d 0a characters can further escalate this injection to high severity vulnerabilities such as XSS, remote code execution, user session hijacking, web cache poisoning, header injection, sensitive information disclosure, and much more. It is a critical vulnerability that should not be taken lightly.
It occurs because the unsanitized input provided by the user is accepted by the browser and sent to the server. The attacker can create his own malicious input and damage the application according to his own benefits and needs.
With this article, we have tried to shed light on some of the effective ways we can prevent CRLF injections. We should check if the supplied input is properly sanitized or not. Unnecessary headers should be disabled, and user-entered input should be properly URL-encoded. We can also use a firewall to prevent CRLF and other attacks.
Head over to our site to better equip your system administrators with different aspects of web security and internet protocols and protect your organization from web attacks.