On 18/02/2013 11:44, André Warnier wrote: > Mark Thomas wrote: >> On 18/02/2013 09:54, Rainer Jung wrote: >>> On 17.02.2013 23:57, André Warnier wrote: >> >>>> Otherwise, my feeling is that it will cost you quite a number of beers >>>> to stop Mark from fixing what could potentially be a security issue, >>>> now >>>> that he's sniffed it. >>> :) >>> >>> Not sure whether Mark's sniffing changes based on the fact that we are >>> now talking about the AJP part of the connectors. >> >> It does mean I'm rather less concerned since that explains why the >> request wasn't rejected with a 400 response. > > Well, the OP did not specifically test with the HTTP Connector, but it > doesn't mean that the issue is not there too..
Very true. I did a quick test and the request is not rejected which surprised me rather. >> I still want to look at this to understand why getRequestURI() is >> behaving the way it is. There might still be a bug here. >> > > Looks like getRequestURI() is behaving according to the Javadocs though, > by providing the original request line undecoded, "as is". The issue is > that the request should probably not even get to the point where it can > be retrieved by getRequestURI(), no ? A little digging and it is clear that the AJP connector is behaving as intended. Any %nn values sent by the client are decoded by the reverse proxy so the AJP message contains (mostly) the raw bytes. There is the potential for a problem here (CVE-2007-0450, CVE-2007-1860) but as long as the reverse proxy is correctly configured (which it is by default - see [1]) all will be fine as the potentially problematic bytes will be re-encoded. While it is a little surprising that getRequestURI() returns characters outside of those defined for uric by RFC2396 given the circumstances I think it is reasonable (for AJP) since that is what Tomcat received. Arguably a byte that represents a character not in uric should be re-encoded using %nn before including it in the return value for getRequestURI() but I don't see a need to implement that. If it was causing a problem somehow then I could be persuaded otherwise. I am more surprised by the HTTP connector. Looking at the code it is clear why this happens. The sequence is: 1. %nn -> byte 2. normalise 3. convert to characters Bytes that should have been %nn encoded but have not, simply skip the first stage and then continue as normal. Where this could get messy is when the client converts multibyte characters to bytes using one encoding and Tomcat converts those bytes to characters using a different encoding. However, while this might cause unexpected behaviour from the client's point of view I don't see how this could cause a problem for Tomcat. Any sequence of bytes that Tomcat ends up processing from stage 2 as a result of byte -> char conversion issues onwards could be sent legally using %nn encoding. Tomcat could justifiably reject these requests as not conforming to RFC 2616. That said, RFC2616 also encourages servers to be tolerant about that they receive from clients and I think this falls into that category. As long as such behaviour does not cause a problem for Tomcat I think it is reasonable to leave the current behaviour as is. The leaves the behaviour of getRequestURI(). It is returning what the client sent so no issue there. Again given a specific issue I'd be prepared to look at %nn encoding for characters not in uric. I agree access to the bytes would be ideal but since bytes are only necessary when going above and beyond what is required by RFC 2616 it isn't surprising that the Servlet EG opted to return a String here. So in summary, not what I was expecting but after some digging I don't see anything that particularly concerns me at this point. > The beer question is still open.. Beers are always welcome. I'll be at ApacheConNA in Portland, OR next week :) Mark [1] http://tomcat.apache.org/connectors-doc/reference/apache.html#Forwarding --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
