Improper Neutralization of CRLF Sequences in HTTP Headers

[s-b-repo]

	SSDPNotifyRequest ssdpReq = new SSDPNotifyRequest();
	ssdpReq.setServer(UPnP.getServerName());
	ssdpReq.setLeaseTime(dev.getLeaseTime());
	ssdpReq.setLocation(devLocation);

lines 661 ,
664, ssdpReq.setUSN(serviceUSN);
686, ssdpReq.setUSN(devUSN);
711, dev.postSearchResponse(ssdpPacket, serviceNT, serviceUSN);
716, dev.postSearchResponse(ssdpPacket, serviceType, serviceUSN);

Unsanitized input from data from a remote resource flows into setHeader and reaches an HTTP header returned to the user. This may allow a malicious input that contain CR/LF to split the http response into two responses and the second response to be controlled by the attacker. This may be used to mount a range of attacks such as cross-site scripting or cache poisoning.

router/java/src/org/cybergarage/upnp/Service.java#L661)

[s-b-repo]

Details

CRLF is an abbreviation for the terms "carriage return" and "line feed." These two special characters are a legacy of old-fashioned printing terminals used in the early days of computing. However, today both are still often used as delimiters between data. When this weakness exists, CR and LF characters (represented respectively in code as \r and \n) are permitted to be present in HTTP headers, usually due to poor planning for data handling during development.

CRLF sequences in HTTP headers are known as "response splitting" because these characters effectively split the response from the browser, causing the single line to be accepted as multiple lines by the server (for example, the single line First Line\r\nSecond Line would be accepted by the server as two lines of input).

While response splitting in itself is not an attack, and can be completely harmless unless exploited, its presence could lead to an injection attack (known as CRLF injection) and a variety of unpredictable and potentially dangerous behavior. This weakness can be exploited in a number of ways, such as page hijacking or cross-user defacement, in which an attacker displays false site content and/or captures confidential information such as credentials. It can even lead to cross-site scripting attacks, in which attackers can cause malicious code to execute in the user's browser.

For example, the following code is vulnerable:

protected void doGet(HttpServletRequest request, HttpServletResponse response) {
Cookie cookie = new Cookie("name", request.getParameter("name"));
response.addCookie(cookie);
}

because the user may provide a name parameter with a value like XYZ\r\nHTTP/1.1 200 OK\nATTACKER CONTROLLED. In this case, they will produce a second HTTP response:

HTTP/1.1 200 OK
ATTACKER CONTROLLED

A possible fix is to remove all non-alphanumerical characters:

protected void doGet(HttpServletRequest request, HttpServletResponse response) {
String name = request.getParameter("name")
.replaceAll("[^a-zA-Z ]", "");
Cookie cookie = new Cookie("name", name);
response.addCookie(cookie);
}

In this case, the attacker would be unable to produce a second HTTP response.
Best practices for prevention

Assume all input is potentially malicious. Define acceptable responses wherever possible, and if not possible, encode CR and LF characters to prevent header splitting.
Replace both \r (carriage return) and \n (line feed) with "" (empty string)-many platforms handle these characters interchangeably so the weakness may still exist if one of the two is permitted. Follow best practices and strip all other special characters (", /, , ;, etc., as well as spaces) wherever possible. Be sure to sanitize special characters in both directions-from the browser to the server and also in data sent back to the browser. Ideally, adopt current development resources, such as languages and libraries, that block CR and LF injection in headers. Be vigilant with all input types that could potentially be tampered with or modified at the user end (intentionally or unintentionally), which could lead to