CRLF Injections and HTTP Response Splitting

Hello, Khabrovites! On the eve of the start of classes in the nearest group of the professional course “Web Application Security”, we have prepared another useful translation for you.

What is CRLF?

When the browser sends a request to the web server, it sends a response that contains the HTTP response headers and the site content itself, that is, the response body. The HTTP headers and the HTML response (site content) are separated by a specific combination of special characters, namely carriage return and line feed. This is abbreviated as CRLF.

The web server uses CRLF to figure out where the new HTTP header starts and the old one ends. Also, CRLF can tell a web application or user that a new line starts in a file or block of text. CRLF characters are a standard HTTP / 1.1 message, so they are used by any type of web server including Apache, Microsoft IIS and others.

What is CRLF Injection?

With CRLF injection, an attacker inserts carriage returns and line feeds into user input to trick the server, web application, or user into thinking that one object has completed and another has started. Thus, CRLF sequences are not malicious characters per se, but can be used by attackers to split HTTP responses (HTTP Response Splitting).

CRLF Injection in Web Applications

For web applications, CRLF injection can have serious consequences, depending on how the application handles the data. The consequences can range from the disclosure of sensitive information to the execution of malicious code, which directly affects the security level of a web application. In fact, a CRLF injection attack can cause serious damage to a web application even though it was not included in the OWASP Top 10. For example, this way you can change the logs in the admin panel, as shown in the example below.

An example of CRLF injection into logs

Imagine a log file in the admin panel with an output stream template IP – Time – Pathas below: - 08:15 - /index.php?page=home

If an attacker can inject CRLF characters into an HTTP request, he can alter the output stream and falsify the logs. It can change the response of the web application to something like this:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Where% 0d and% 0a are URL encoded CR and LF characters. Thus, after the attacker inserts these characters, and the application displays them, the logs will look like this:

IP – Time – Path - 08:15 - /index.php?page=home& - 08:15 - /index.php?page=home&restrictedaction=edit

Thus, using CRLF injections, an attacker can spoof log entries to cover their tracks. The attacker literally hijacking the page and alters the response. For example, imagine a scenario in which an attacker has an administrator password and the parameter restrictedactionthat only an administrator can use.

The problem is that if the administrator notices that the unknown IP is using the parameter restrictedaction, it will understand that something is wrong. However, as long as it looks like the command was issued by localhost (and therefore probably by someone who has access to the server, such as an administrator), this will not look suspicious.

The part of the request starting with% 0d% 0a will be processed by the server as one parameter. After that, another & appears with the parameter restrictedaction, which will be perceived by the server as another parameter. Basically, this will be the same query as:


HTTP Response Splitting


Since the HTTP response header and body are separated by CRLF characters, an attacker could attempt to inject them. The CRLFCRLF combination will tell the browser that the header ends and the body begins. So now it can write data to the response body where the HTML code is. This can lead to a cross-site scripting vulnerability.

Example HTTP Response Splitting Leading to XSS

Imagine the application is setting its own header, for example:

X-Your-Name: Bob

The header value is set using the “name” GET parameter. If there is no URL encoding and the value is simply contained in the header, then an attacker could insert the above CRLFCRLF combination to tell the browser to start the request body. This is how it can insert data, such as an XSS payload:

? name = Bob% 0d% 0a% 0d% 0a

The above will display an alert box in the context of the attacked domain.

HTTP Header Injection


Through CRLF injection, an attacker can also inject HTTP headers that can be used to bypass security mechanisms such as browser XSS filter or same-origin-policy. This is how an attacker can obtain confidential information such as CSRF tokens. It can even set cookies, which can be exploited by the victim logging into the attacker’s account or exploiting the vulnerability cross-site scripting (XSS)

Example of HTTP header injection to retrieve sensitive data

If an attacker can inject an HTTP header that enables Cross Origin Resource Sharing (CORS), then he can use javascript to access resources protected by the Same Origin Policy (SOP), which prevents sites from different sources from accessing each other.

Consequences of CRLF injection

The consequences of CRLF injection vary and can include all the consequences of using XSS and disclosing sensitive information. In this way, it is possible to deactivate some security restrictions, such as XSS filters and Same Origin Policy in the victim’s browsers, making them vulnerable to malicious attacks.

How to prevent CRLF / HTTP header injection in web applications

The best prevention method is not to use user input directly in the response header. If this is not possible, you should always use the function to encode CRLF special characters. Another good security practice is to update the programming language to a version that does not allow CR and LF injections inside functions that set HTTP headers.

Vulnerability classification table and their severity

More about the course “Web Application Security”

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *