HTTP Response Splitting entails a kind of attack in which an attacker can fiddle with response headers that will be seen by the client. The attack is simple: an attacker passes malicious data to a vulnerable application, and the application includes the malicious data in the single HTTP response, thus leading a way to set arbitrary headers and embedding data according to the whims and wishes of the attacker.
In the HTTP Splitting attack, there are always three parties involved.
- Web server– This has a web application security weakness that leads to HTTP Response Splitting.
- Victim – It is generally the cache server or the browser itself that talks with the webserver on behalf of the hacker/attacker.
- The attacker who initiates the attack.
The attack scenario is basically the attacker’s ability to send an HTTP (or HTTPS port 443)request which forces the server to form such a response that when it reaches the target, it is interpreted by the target as two responses instead of one. The attacker partially controls the first response. However, the most important part of the attack is that the attacker has complete control over the second response starting from the HTTP status line to the last byte of the HTTP response body.
Once this is done, the attacker launches the attack by sending two requests to the victim. What these requests basically do is that the first single HTTP request provokes two HTTP responses from the server; however, the second one would be a normal request that we send to the server to access resources on the website. This second “normal” request is the request where the magic happens. This request is matched to the response that is fully controlled by the hacker, but the victim believes this is a genuine response from the server and hence, gets compromised via this HTTP response splitting attack.
To view a concise version of this article, we invite you to watch our video on the same topic.
What is an HTTP Host header attack?
HTTP Host header attacks exploit vulnerable websites that do not sanitise the value of the Host header. If the server implicitly trusts the Host header and fails to validate or escape it properly, an attacker can use this input to inject harmful payloads containing malicious characters and manipulate the server-side behaviour of the web application.
Such type of attacks that involve injecting a payload directly into the Host header is often known as “Host header injection” attacks.
When is the application vulnerable to an HTTP response header attack?
When the data entered in the HTTP request is not from a trusted source, the web server can be vulnerable to the attack. Then the data is included in an HTTP response and is sent to the client without being sanitised for malicious characters.
Before showing the attack in action, we need to understand a few terms here.
What are CRLF and HTTP headers?
CR in CRLF simply stands for carriage return, also given by the special characters’ %0d’, or \r and LF in CRLF stands for line feed, also given by ‘%0a’ or \n. Hence the name CRLF.
The HTTP protocol consists of the header section. In this section, several things can be transmitted, such as URI, cookies, server information and status codes. These headers are interpreted by the web server or client.
Now that we know what HTTP header and CRLF means, let’s understand how this attack actually works and which functionality of the application we exploit.
What are the types of attacks via HTTP response splitting?
Cross-site Scripting (XSS)
XSS is one of the topmost attacks in web application security and OWASP top 10 list each year. A common attack is injecting a second HTTP response and HTML content, which then leads to XSS.
`location` XSS attack
Most of the HTTP Response Splitting vulnerabilities occur due to the value of the `Location` header not being sanitised thoroughly. This poses a problem for the attacker as the browser will do the redirect if we don’t have full control over the Location header hence our attack fails as the malicious code would be ignored, and redirection will take place instead, foiling the attack. Other HTTP headers that may be vulnerable to this type of attack can be Set-Cookie and Link header which we will discuss later on in the article.
As discussed above, this attempt will be failed attack as redirection will happen to /somedir, and the injected code will be simply ignored.
In the same example, if the attacker had full control over the Location HTTP response headers, it allows the attacker full control over the header and can change the request and inject malicious code.
Based on the example, the location header is not empty and no redirections are happening, therefore, the malicious code that was submitted will be processed.
If the attacker has control over HTTP headers other than `Location`, then the XSS attack is simple as the attacker need not worry about the redirect that would have taken place in case of a Location header attack. Headers that may also be vulnerable to HTTP response splitting are `Link` and `Set-Cookie` as they often can be controlled by the user.
‘Set-cookie’ HTTP request header attack
The HTTP header Set-cookie, which is used to set a new cookie for the users/clients of the web applications, can also be a common vector for HTTP response splitting attack, which can lead to Session fixation or if the value of the cookie is not sanitised it can even lead to XSS.
Example: The browser sends the set-cookie header in the HTTP request
The HTTP response from the server will be:
The victim’s browser then saves a cookie with the value of “username=”. If the website uses this parameter to return the username on the website page, it will not return the username after a successful attack. For example, the website returns “Welcome “, which would now only return “Welcome”.
As the attacker controls the parameters and the request headers here, headers of the HTML content can be modified accordingly. Consequently, some headers are reflected in the HTML. These headers can contain sensitive data or user data exposing exact details of the web user, thus, compromising sensitive information and security.
CRLF injection
What is the CRLF injection vulnerability?
We already understand what CRLF is. What is still left unexplained is that we can possibly exploit CRLF to perform a CRLF injection attack.
In a CRLF injection attack, the attacker inserts the carriage return (CR) and linefeed (LF characters into user input to manipulate the server, the web application, or the user into thinking that an object has terminated and another one has started.
While CRLF characters are not malicious themselves, they can be used with malicious intent, for example, HTTP response splitting.
CRLF injection in web applications
CRLF injection can have a vital impact on the content supplied in a web browser; it depends on how the application interprets the request block. The impact of this attack can vary from information disclosure to code execution. Let’s see the attack in action and understand the impact it can create on web users and web servers.
Example: CRLF injection in a log file
This attack consists of a log file in an admin panel with the output stream pattern of login details, their IP addresses, usernames and passwords, as given below.
If the web application is vulnerable to CRLF Injection, the attacker can change the output and fake log entries and introduce other hazardous characters to manipulate the admin. The response from the server can be changed to:
URL-encoded data forms of CR and LF are %0d and %0a. Hence, the log entries after the attack will look like this after the attacker has inserted those “malicious” characters and the application displays them.
After a successful attack, the attackers can fake entries into the log file to conceal their attack.
The query can be understood as %0d%0a which will be handled by the server as one parameter and the & after the restricted action parameter will be parsed by the server as another parameter.
Mitigation
Response Splitting :- On the server, all the CRLF characters must be disallowed where user input (usually untrusted source) is reflected in the response header.
XSS: White List and Black List filtering (Input Validation).
The content security policy should also be defined in HTML.
OWASP guide to HTTP response splitting topic:
https://owasp.org/www-community/attacks/HTTP_Response_Splitting
CRLF Injection Attack Reports
Shahrukh, is a passionate cyber security analyst and researcher who loves to write technical blogs on different cyber security topics. He holds a Masters degree in Information Security, an OSCP and has a strong technical skillset in offensive security.
