Checkers:SV.HTTP_SPLIT

From current

Reference > Java checkers > SV.HTTP SPLIT

This error is reported when a value from an HTTP client or database appears, without validation, in a method that writes to an HTTP header. The SV.XSS.* checkers cover similar attacks.

Vulnerability and risk

"HTTP Response Splitting" is a technique for attacking applications. It enables various new attacks such as web cache poisoning, cross-user defacement, hijacking pages with sensitive user information and cross-site scripting (XSS). This attack technique, and the attacks that are derived from it, can happen in most web environments and result from an application not rejecting illegal user input such as malicious or unexpected characters.

The essence of HTTP Response Splitting is the attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of the normal single response. The first response may be partially controlled by the attacker, but this is less important. What is more important is that the attacker completely controls the form of the second response (header). Once this is possible, the attacker can complete the attack by sending two requests through the target. The first one invokes two responses from the web server, and the second request would typically be to some innocent resource on the web server. However, the second request would be matched, by the target, to the second HTTP response, which is fully controlled by the attacker. The attacker therefore tricks the target into believing that a particular resource on the web server (designated by the second request) is the server's HTTP response (server content), while it is in fact data forged by the attacker through the web server -- this is the second response.

Klocwork Insight security vulnerability (SV) checkers identify calls that create potentially dangerous data; these calls are considered unsafe sources. An unsafe source can be any data provided by the user, since the user could be an attacker or has the potential for introducing human error. See also Examples of unsafe data sources for Java security vulnerability (SV) checkers.

Mitigation and prevention

Validate all input data, even when coming from a semi-trusted source such as a database. Especially check for a Carriage Return followed by a Line Feed (CRLF) combination.

Example 1

15     protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
16         String url = req.getParameter("HIDDEN_URL");
17         if (url.length() == 0) {
18             generatePage(req, resp);
19         } else {
20             resp.sendRedirect(url);
21         }
22     }
23 
24     private void generatePage(HttpServletRequest req, HttpServletResponse resp) throws IOException {
25         PrintWriter wr = resp.getWriter();
26         wr.print("Hello, World!");
27     }

SV.HTTP_SPLIT is reported for line 20: 'url' contains data coming from an HTTP request parameter and might be tainted (line 16). This value is used to send an HTTP redirect on line 20.

Security Guidelines