Generic HTTP Response Splitting Scanner

HTTP servers and web application frameworks are used to deliver web content and APIs to clients across the internet. They are deployed by organizations of all sizes and by developers building web-facing services. Common implementations include standalone web servers, reverse proxies, and embedded HTTP handlers inside application frameworks. These components are responsible for constructing HTTP responses including status lines, headers, and bodies. Because headers are constructed from input that may come from various sources, improper handling of header content can introduce parsing vulnerabilities. This scanner targets those environments where header construction is influenced by user-controlled data.

HTTP Response Splitting is caused when an application or server includes unvalidated input in HTTP headers and an attacker injects CRLF (carriage return and line feed) sequences to prematurely terminate a header or create additional response headers or whole responses. This can enable a range of attacks including cache poisoning, cross-user defacement, header manipulation, and smuggling additional responses to downstream clients. The issue typically arises where application code concatenates strings into header values without normalizing or removing control characters. Modern frameworks sometimes mitigate this, but many legacy or custom implementations remain vulnerable. The severity depends on the context and what headers or content can be influenced. Detecting header injection points is therefore critical to prevent downstream abuses.

The vulnerability is usually present at endpoints that echo user input into response headers (for example, Location, Set-Cookie, X-Forwarded-For, or custom headers) or in proxy/redirect logic building header values from query parameters, form fields, or path segments. An attacker supplies input containing %0d%0a (URL-encoded CRLF) or raw CR and LF characters which the server fails to sanitize, causing the header to be split and additional headers or responses to be injected. A typical exploit sequence involves sending a crafted request that sets a header value to: valid-value%0d%0aInjected-Header: injected-value%0d%0a%0d%0a<body-of-new-response>. Vulnerable middleboxes or caches can store the malicious response, enabling cache poisoning or cross-user content delivery. Detection requires confirming that injected CRLF sequences result in new header lines or separate HTTP responses in the server's output. The scanner verifies this by sending controlled payloads and analyzing response headers and body structure for evidence of splitting.

When exploited, attackers can perform cache poisoning to serve attacker-controlled content to other users, conduct HTTP header manipulation to bypass security controls, or insert malicious headers that change downstream behavior. In some cases, it enables cross-user defacement, where cached responses display attacker content to multiple victims. It can also facilitate session fixation or cookie manipulation if Set-Cookie headers are affected. Combined with other flaws, response splitting may allow persistent attacks through intermediary caches or proxies. Even if direct RCE is not possible, the impact on trust, integrity of cached content, and user privacy can be significant.

REFERENCES

• https://owasp.org/www-community/attacks/HTTP_Response_Splitting
• https://cwe.mitre.org/data/definitions/113.html