Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> [EMAIL PROTECTED] wrote: >>> Add simple URI normalizer that can deal with things like %252e%252e. >>> This is mostly copy/paste from the IIS module >> >> You have me way confused ;-) >> > > How it works: > Imagine you have two applications on Tomcat appA and appB, and > you wish *only* to expose the appA via > JkMount /appA/* worker > > Request: > http://host/appA/%252e%252e/appB/ This request, assuming appA is a valid context, is for a directory listing for: <appA DocBase>/%2e%2e/appB/
This is a perfectly valid request that should be honoured if the directory exists and listing is enabled or a 404 returned if it does not. It should not matter if httpd + mod_jk + tomcat is used or just tomcat. > mod_jk 1.2.22 (with default passing r->uri) will serve /appB/ Obviously bad from a security perspective. > mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404 > from Tomcat becasue it will pass the original uri, not the one Httpd > already unfolded) This is correct and provides consistent behaviour for direct to Tomcat access and access via mod_jk. > mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount > /appB/* This double decoding prevents legitimate access to perfectly valid files that contain the % character in their name. >> This has some very ugly side >> effects for legitimately escaped paths, +1 >> and if it is a security precaution, >> don't you just leave yet-a-new-hole for triply-folded uris? I haven't tested this but probably not. If I understand the patch correctly, httpd will undo one level, mod_jk will undo a second and test the mappings and Tomcat will be passed the url httpd unfolded so it will still be double-folded at this point. Tomcat will unfold once more and fail to map the url. > Again, no. It doesn't touch the original uri. > Request for http://host/appA/%252e%252e/appB/ will be unfolded by > httpd to http://host/appA/%2e%2e/appB/ before it hits mod_jk. > Inside map_uri_to_worker it will be unescped (locally) to > /appA/../appB/ and the normalized to /appB/ and then it looks for > mounted path. In case one have JkMount /* or JkMount /appB/*, the > original uri host/appA/%2e%2e/appB/ will be passed to Tomcat. But this is wrong. The url should only be decoded once in the processing chain. I can see how this would provide a safe alternative for users that the 1.2.23 fix caused problems for but I do not believe it should be the default. I would suggest: - keep the 1.2.23 behaviour (+ForwardURICompatUnparsed) as the default - modify the ForwardURICompat option to include this additional check This approach: - maintains the security of 1.2.23 - ensures the url is decoded only once by default - provides a safe option for users that want/need/expect double decoding --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
