Code Review on a Header Injection In Java : any help?

Question

I'm auditing a piece of Java code that might be vulnerable to header injection :

String headerValue =request.getParameter("headerVal");

//escaping CRLF
headerValue = headerValue.replace("\n", "");
headerValue = headerValue.replace("\r", "");
response.addHeader("myheader",redirection);

This code is present directly in the layer view (jsp).

As far as i know this piece of code completely do not take into account that CRLF could injected in different encoding according to my readings.

In other words, I would like to report to the DEV team as a Canonicalization issue.

Because I think that developers will deny it, I'm trying to setup a proof of concept with a HelloWorld project with Tomcat6 but it seems tomcat is preventing this in background.

Do you have any arguments other than Canonicalization to justify this flaw? Or Am I strongly wrong and this code is safe ? Thank you in advance.

Frenchy

Answer 1

In principle HTTP headers are ISO-8859-1 according to RFC 2616. In practice non-ASCII content in HTTP headers will be in a different encoding depending on the browser (and for IE also locale), but always an ASCII superset. Consequently CR and LF would invariably be encoded as 0x0D and 0x0A so there shouldn't be anything to worry about if you are replacing those.

The only point at which encoding would come into play would be for UTF-8 overlong sequences. For example 0x0A could be encoded as 0xC0 0x8A. This is invalid, but has been accepted by various UTF-8 decoders in the past. So, if:

• you're using a non-UTF-8 [default] encoding in your web app, so that this byte sequence would get through without Java complaining it was an overlong, and
• the user-agent you were sending the header to were to decode headers en bloc using UTF-8, and
• the user-agent permitted overlong UTF-8 sequences

then yes, you could get header smuggling attacks by reflecting a parameter into a response header.

With today's user-agents this is a pretty unlikely proposition, but in general I would say it's worth removing all non-ASCII characters from header values, just because they're handled so inconsistently across browsers as to be useless in any case. I'd also recommend filtering out all the control characters 0x00–0x1F, not just newlines.