HTTP response splitting is a web application vulnerability that occurs when an application includes user-supplied data in HTTP response headers without proper validation.
This vulnerability allows an attacker to manipulate the HTTP response headers and body, potentially creating two separate HTTP responses from a single request.
HTTP response splitting occurs when:
Data enters a web application from an untrusted source, most commonly through an HTTP request.
This data is included in an HTTP response header sent to a web user without validation for malicious characters.
HTTP response splitting is a means to an end rather than an end. At its core, the attack is straightforward: an attacker provides malicious data to a vulnerable application, which then includes this data in an HTTP response header.
For a successful exploit, the application must allow input that contains CR (carriage return, represented as %0d or \r) and LF (line feed, represented as %0a or \n) characters into the header.
Additionally, the underlying platform must be vulnerable to the injection of these characters. These characters give attackers control over the remaining headers and body of the response the application intends to send and allow them to create additional responses entirely under their control.
Example
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
How does HTTP response split vulnerability work?
Data entry: An attacker sends data to the web application, typically through an HTTP request. This data includes special characters like CR (carriage return, represented as %0d or \r) and LF (line feed, represented as %0a or \n).
Header injection: The application includes this unvalidated data in the HTTP response headers.
Response manipulation: The CR and LF characters can be used to terminate the headers prematurely, allowing the attacker to inject additional headers and content into the response. This can result in multiple HTTP responses being sent to the client.
What are the impacts of HTTP response splitting vulnerability?
HTTP Response Splitting vulnerabilities can have significant and varied impacts on web applications and their users. The potential consequences include:
1. Cross-Site Scripting (XSS)
Attackers can inject malicious scripts into the response body. When a user accesses the manipulated page, the script executes in their browser, potentially stealing sensitive information such as cookies, session tokens, or user credentials.
2. Cache poisoning
By manipulating the HTTP response, attackers can poison caches on intermediary proxies or content delivery networks. This results in malicious responses being served to other users.
3. Session fixation
Attackers can manipulate session cookies by injecting headers that set or overwrite cookies. This can force users into sessions controlled by the attacker.
4. Unauthorized information disclosure
Malicious headers can expose sensitive information to unauthorized users.
5. Request/response manipulation
Attackers can manipulate how the server processes requests and responses, leading to various attacks, such as unauthorized actions or misrouting of data.
An attacker splits the response and includes headers that change the behavior of subsequent requests.
6. Security policy bypass
By injecting or altering headers, attackers can bypass security policies like Content Security Policy (CSP) or HTTP Strict Transport Security (HSTS) An attacker injects headers that disable CSP, making XSS attacks easier to execute.
How can you prevent HTTP response splitting vulnerability?
Preventing HTTP response splitting vulnerabilities involves several key practices focused on input validation, encoding, and leveraging modern security features. Here are the primary prevention methods:
1. Input validation
Ensure that any data originating from user input is validated before it is included in HTTP response headers. Reject or sanitize inputs that include CR (%0d) and LF (%0a) characters.
Use a whitelist approach to allow only expected characters in user inputs, especially for data included in headers.
2. Header encoding
Properly escape or encode CR and LF characters to prevent them from being interpreted as control characters within headers.
Utilize built-in functions and libraries that safely handle header encoding to ensure no special characters can be injected.
3. Use modern frameworks and servers
Use modern web frameworks that have built-in protections against HTTP Response Splitting. Many frameworks automatically sanitize and encode data in headers.
Ensure that the web server and application framework are up to date with the latest security patches and updates.
4. Content Security Policies (CSP)
Implement Content Security Policy headers to reduce the risk of XSS attacks if response splitting does occur. CSP can help control what resources can be loaded and executed on the page.
5. Web Application Firewalls (WAF)
Use a Web Application Firewall to detect and block malicious input that could exploit response splitting vulnerabilities.
6. Secure coding practices
When setting headers, always use the framework’s provided methods rather than manually constructing header strings.
Minimize the use of user-supplied data in HTTP headers where possible. If necessary, ensure the data is strictly validated and encoded.
By adhering to these practices, developers can significantly reduce the risk of HTTP Response Splitting vulnerabilities in their applications.
