Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question
    
In that final line of code, is using the value of redirection as header value a mistake (I imagine it should be headerValue)? –  Michael Kjörling Dec 29 '11 at 14:08
add comment

1 Answer

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.

share|improve this answer
    
+1, your answer really provides alot of insight to the common belief that you should just filter /r /n. Nice answer. –  Chris Andrè Dale Dec 28 '11 at 23:01
    
Thank you for your technical and detail response and the dedicated time given. To show you my deep gratitude, I will adopt a frog ;) –  Omar EL Mandour Dec 29 '11 at 11:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.