CRLF Injection and HTTP Response Splitting Vulnerability
In this post, we discusses how HTTP Response Splitting vulnerabilities can be exploited via CRLF injection attacks, and how to prevent this in your web app.
Join the DZone community and get the full member experience.Join For Free
What Is CRLF?
When a browser sends a request to a web server, the web server answers back with a response containing both the HTTP headers and the actual website content. The HTTP headers and the HTML response (the website content) are separated by a specific combination of special characters, namely a carriage return and a line feed. They are also known as CRLF.
The server knows when a new header begins and another one ends with CRLF, which can also tell a web application or user that a new line begins in a file or in a text block.
What Is the CRLF Injection Vulnerability?
In a CRLF injection vulnerability attack, the attacker inserts carriage return, linefeeds both of the characters into the user input to trick the server, web application or the user into thinking that an object is terminated and another one has started.
CRLF Injection in Web Applications
In web applications, a CRLF injection can have severe impacts, depending on what the application does with single items. Impacts can range from information disclosure to code execution. For example, it is also possible to manipulate log files in an admin panel as explained in the below example.
An Example of CRLF Injection in a Log File
Imagine a log file in an admin panel with the pattern IP - Time - Visited Path. Therefore, entries appear like:
18.104.22.168 - 08:15 - /index.php?page=home
If an attacker is able to insert the CRLF characters into the query he is able to fake those log entries and change them into:
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
%0d and %0a is the URL encoded form of CR and LF. Therefore, the log entries would look like this after the attacker inserted those characters and the application displays it:
IP - Time - Visited Path
22.214.171.124 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
Therefore, by exploiting a CRLF injection vulnerability, the attacker can fake entries in the log file to obfuscate his own malicious actions. For example, imagine a scenario where the attacker has the admin password and executed the restrictedaction parameter, which can only be used by an admin.
The problem is that if the administrator notices that an unknown IP used the restrictedaction parameter, they will notice that something is wrong. However, since it now looks like the command was issued by the localhost (and, therefore, probably by someone who has access to the server, like an admin) it does not look suspicious.
The whole part of the query beginning with
%0d%0a will be handled by the server as one parameter. After tha,t there is another
& with the parameter restrictedaction which will be parsed by the server as another parameter. Effectively, this would be the same query as:
HTTP Response Splitting
Since the header of an HTTP response and its body are separated by CRLF characters, an attacker can try to inject those. A combination of CRLFCRLF will tell the browser that the header ends and the body begins. That means that he is now able to write data inside the response body where the HTML code is stored. This can lead to a Cross-Site Scripting vulnerability.
An Example of HTTP Response Splitting Leading to XSS
Imagine an application that sets a custom header, for example:
The value of the header is set via a GET parameter called "name." If no URL encoding is in place and the value is directly reflected inside the header it might be possible for an attacker to insert the above-mentioned combination of CRLFCRLF to tell the browser that the request body begins. That way he is able to insert data such as XSS payload, for example:
The above will display an alert window in the context of the attacked domain.
HTTP Header Injection
By exploiting a CRLF injection an attacker can also insert HTTP headers which could be used to defeat security mechanisms such as a browser's XSS filter or the same-origin-policy. This allows the attacker to gain sensitive information like CSRF tokens. He can also set cookies which could be exploited by logging the victim in the attacker's account or by exploiting otherwise unexploitable cross-site scripting (XSS) vulnerabilities.
An Example of HTTP Header Injection to Extract Sensitive Data
Impacts of the CRLF Injection Vulnerability
The impact of CRLF injections vary and also include all the impacts of Cross-Site Scripting to information disclosure. It can also deactivate certain security restrictions like XSS Filters and the Same Origin Policy in the victim's browsers, leaving them susceptible to malicious attacks.
How to Prevent CRLF/HTTP Header Injections in Web Applications
The best prevention technique is to not let users supply input directly inside response headers. If that is not possible, you should always use a function to encode the CR and LF special characters. It is also advised to update your programming language to a version that does not allow CR and LF to be injected into functions that set headers.
Vulnerability Classification and Severity Table
|Classification||ID / Severity|
Published at DZone with permission of Sven Morgenroth, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.