tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
Date Wed, 06 Jun 2007 01:53:51 GMT
Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>> 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

> 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,

>> 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

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:
For additional commands, e-mail:

View raw message