HTTP Response Splitting is a type of attack that occurs when an attacker can manipulate the response headers that will be interpreted by the client. The Detectify Security Research team shows with details on how this can be abused by an attacker to insert arbitrary headers and the impact of this type of attack.
But first… HTTP headers and CRLF
The HTTP protocol partly consists of the header section and the body of each response and request between a web server and a client. In the headers section several things can be transmitted such as URI, cookies, server information and status codes. These headers will be interpreted by the web server or client.
A simple HTTP response (from the server) may look something like:
In the above response we can see rn after each line which are two characters, carriage return (r) and a line feed (n), also abbreviated as CRLF. In the HTTP specification, you can set a CRLF to specify the end of the header.
How HTTP Response Splitting exploitations work
One of the most common attacks are to inject a second HTTP-response with defined headers and HTML content, which then leads to XSS. A vast majority of HTTP Response Splitting vulnerabilities occur due to the value of the `Location` header is not properly sanitized, and this is problematic for hackers as the browser will do the redirect and the hackers injected HTML will be ignored.
Imagine the following HTTP response (the red part is injected by the hacker):
The above attempt won’t be successful because the web browser will redirect to /username and the injected HTML will simply just be ignored.
But what if the attacker had complete control over the value in the `Location` header?
Because the `Location` value is empty, the web browser will ignore that header, meaning that the rest of the headers will be parsed by the web browser. As a result, no redirect will be made which means that the above attack would be successful.
If the attacker can control headers other than `Location`, then XSS is very easy as no redirect will take place that would otherwise ignore the injected headers. Headers that also may be vulnerable to HRS are `Link` and `Set-Cookie` as they often can be controlled by the user.
How about ‘Set-cookie’?
Another common attack is to inject a `Set-Cookie` header which will set a new cookie for the user. This can lead to Session Fixation, or even XSS if the value of the cookie is somewhere reflected and not sanitized. Example:
Which the server then will respond with:
The web browser then saves a cookie with the value of “username=”. If the website outputs this somewhere, for example in this context: “Welcome back username”, it would then display “Welcome back”
Because the attacker can control the headers, it is possible to split the headers from the HTML content, and consequently some headers are reflected in the HTML (see first image). In some cases this can be headers with sensitive information, such as `Set-Cookie` thus bypassing cookie attributes such as `HttpOnly`. XSS via HRS can therefore be much more serious than standard XSS.
Learn more on HTTP-headers and the basics to securing web browsers here.
Mitigations
- Properly sanitize values in the `Location` header. Filter characters such as r and n
- Don’t let users control the whole value in the `Location` header
- When using a Content-Security-Policy, it should also be defined in the HTML
How does Detectify help?
Using Detectify’s online vulnerability scanner, you can check whether your web applications are vulnerable to HTTP-response splitting exploitations mentioned in this article. We also check for other HTTP-header vulnerabilities.
image: this shows how HTTP response splitting tests appear in the Detectify tool UI
Detectify is automated web application scanner checking for 1000+ known vulnerabilities including OWASP Top 10 and SSRF. Start your Detectify free trial today to see whether your applications are missing HTTP headers and more.
Written by:
Kristian Bremberg
Edited by:
Jocelyn Chan