HTTP Response Splitting
Play Labs on this vulnerability with SecureFlag!
Description
HTTP Response Splitting occurs when a web server fails to sanitize CR and LF characters before the data is included in outgoing HTTP headers.
To launch a successful exploit, the application must be vulnerable to the injection of Carriage Return (CR, ASCII 13, \r) and Line Feed (LF, ASCII 10, \n) characters, which are used in the HTTP protocol to terminate a line, into the response header. This technique is also referred to as “CRLF Injection in HTTP Headers”, and it gives attackers control of the remaining headers and body of the response that the application will send.
Impact
The vulnerability allows the attacker to set arbitrary headers, take control of the body, or break the response into two or more separate responses. Impacts depend on the technological stack, with outcomes including Cross-Site Scripting, Cookie Injection, CORS Headers Injection, CSP (Content Security Policy) Bypass, Cache Poisoning attacks, and many others.
FrontJacking
FrontJacking is a hacking technique that involves CRLF (Carriage Return Line Feed) injection, HTTP request header injection, and cross-site scripting (XSS) to exploit a poorly configured reverse proxy in a shared hosting environment. The ultimate goal of FrontJacking is to hijack the frontend server and replace it with attacker-controlled content, allowing a complete bypass of defensive measures.
Attackers can inject host headers with HTTP request header injection, allowing for request smuggling to make multiple requests. This technique is instrumental in a shared hosting environment, where an attacker can use it to make requests to other servers.
This results in the attacker being able to control the content of the frontend server, which can be used to inject malicious code into the frontend server. This can be used to steal session cookies, which can be used to hijack the user’s session and perform malicious actions on their behalf.
Scenarios
Attacks such as Cross-Site Scripting and Cookie Injection are delivered by tricking the user into clicking on a malicious link. The injected code travels to the vulnerable website, which reflects the attack payload back to the user’s browser. The browser then executes the injected code because it came from a “trusted” server.
In a Cookie Injection scenario, imagine a web application that, in case of error, redirects the user while reflecting GET parameters in the Location header:
/?error=Page+Not+found
HTTP/1.1 301 Moved Permanently
Location: /index?error=Page+Not+Found
If the value is directly reflected inside the header with no sanitization or encoding, it might be possible for an attacker to inject the CRLF sequence to insert a new header or a new body.
In this example, the attacker tricks the victim into visiting the following URL:
/?error=Page+Not+found%0d%0aSet-Cookie:+cookie=this_value_has_been_injected!
This results in the server sending the following response to the victim:
HTTP/1.1 301 Moved Permanently
Location: /index?error=Page+Not+Found
Set-Cookie: cookie=this_value_has_been_injected!
The victim’s browser now considers the injected cookie as legitimate and, depending on the application, can be used to launch further attacks, such as Session Fixation or, if the value of the cookie is somewhere reflected and not sanitized, Cross-Site Scripting attacks.
Prevention
As with other similar injection attacks, HTTP Response Splitting can be mitigated by performing appropriate server-side validation and escaping. The canonical ways are the following:
-
Carefully validate and sanitize any user-provided content that might be used to compose response headers.
-
Encode dangerous characters such as
\rand\n.
Testing
Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.
- OWASP ASVS: 5.2.2
- OWASP Testing Guide: Testing for Host Header Injection, Testing for HTTP Splitting Smuggling
References
OWASP - HTTP Response Splitting
CWE - 113 - Improper Neutralization of CRLF Sequences in HTTP Headers