On 17.02.2013 23:57, André Warnier wrote: > Mike Wilson wrote: >> Mark Thomas wrote: >>> On 17/02/2013 16:54, André Warnier wrote: >>>> Mike Wilson wrote: >>> <snip/> >>> >>>>> Example 2: path /ä in "binary" Unicode >>>>> GET /.. [0xC3,0xA4] >>>>> request.getRequestURI() -> "/.." [0xC3,0xA4] >>>>> request.getPathInfo() -> "/ä" >>> <snip/> >>> >>>> I believe that your example #2 above is simply illegal. >>>> One is not supposed to send such bytes in a URL without >>> URL-encoding them. >>>> That's per the HTTP RFC itself : >>>> RFC 2616 3.2.2 & 3.2.3 >>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2) >>>> -> RFC 2396 part 2. URI Characters and Escape Sequences >>>> (http://www.ietf.org/rfc/rfc2396.txt) >>>> >>>> And I believe that the fact that Tomcat is returning the "correct" >>>> translation in the corresponding request.getPathInfo() is purely >>>> accidental, and it could be argued that this is a bug in >>> Tomcat : the >>>> request should probably have been rejected, because the >>> requested URL >>>> was invalid. >>> +1. It is on my list of things to do to check why this wasn't >>> rejected with a 400 response. >>> >>> Mark >> >> Explicitly making this invalid is probably fine, although it might >> be looked upon as "breaking" working systems. Note that we have >> apparently been running with a setup sending these binary URLs >> for years, where mod_jk is the source of the invalid URLs. >> Ie, the browser sends a nice URL-encoded URL which is decoded by >> mod_jk before sending to Tomcat. >> >> So might be appropriate to hold off this change to a release where >> back compat isn't crucial? >> > > Mmmm. > It stretches the imagination a bit to imagine that mod_jk by default > takes a valid URL and makes it invalid before forwarding it to Tomcat.
The web server will first decode the URL to be able to do whatever it is configured to do. When mod_jk needs to forward the request, there's a decision needed: - using the original undecoded URL: that seems to be safe, but means it will be incompatible with any URL rewritng configured in Apache, e.g. using mod_rewrite - using the final decoded and maybe rewritten URL: this is insecure, because it can be used for double-encoding attacks. - using the final decoded and maybe rewritten URL, but re-encoding any bytes that doe not seem to be safe: that's what mod_jk currently does by default. > As far as I recall, there are several options in mod_jk (ForwardURI* > family) which allow to do things there, some of them unsafe. Right, see above. The default should be safe. > So it raises the question : are you doing something until now which is > considered as unsafe, and therefore are having that problem ? > (And a linked question is whether by changing this mod_jk option you > could restore operability with a Tomcat rejecting the invalid URLs). > > 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. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
