On Wed, 25 Jun 2003, Palle Girgensohn wrote:
> setup:
>
> FreeBSD 4.8-RELEASE, apache 1.3.27 w/ mod-ssl 2.8.14, mod_jk 1.2.3 and
> 1.2.4. Tomcat version is irrelevant since the request never leaves apache,
> but anyway, it is tomcat 3.3.1a.
>
> JkMount /pp/system/*jsp
>
> [Wed Jun 25 01:32:48 2003] [jk_uri_worker_map.c (460)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Wed Jun 25 01:32:48 2003] [jk_uri_worker_map.c (477)]: Attempting to map
> URI '/pp/entrance/login.jsp'
> [Wed Jun 25 01:32:48 2003] [jk_uri_worker_map.c (558)]:
> jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match tomcat -> *.jsp
> [Wed Jun 25 01:33:14 2003] [jk_uri_worker_map.c (460)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Wed Jun 25 01:33:14 2003] [jk_uri_worker_map.c (477)]: Attempting to map
> URI '//pp/entrance/login.jsp'
> [Wed Jun 25 01:33:14 2003] [jk_uri_worker_map.c (599)]:
> jk_uri_worker_map_t::map_uri_to_worker, done without a match
>
> map_uri_to_worker just makes an exact match, in my case "//pp/system"
> against "/pp/system/", actually on line 485:
>
> if(0 == strncmp(uwr->context,
> uri,
> uwr->ctxt_len)) {
>
> double slashes after /pp/system/ are OK, they will be sent on to tomcat,
> which has code to handle this.
This reflects a design problem in mod_jk. Instead of using Apache's
support for <Directory> sections and handlers, it attempts to
reimplement it on its own. This is one example of where it doesn't
work and exposes a security issue. There are a lot of other examples,
especially on windows, where there is a lot of filename variance.
When you are "protecting" (in this case, by forwarding to something
else to handle them) files, you will expose yourself to a wide
variety of security holes if you attempt to do so based on URI
instead of on the canonical version of the path.
There is a related problem in mod_jk2 that I ran into, which results
in breaking any attempt to use a DirectoryIndex setting with
"index.jsp" or some such in it. If you configure mod_jk2 to
handle *.jsp, it assumes that if you get a request for "foo.jsp" then
tomcat should handle it even if foo.jsp doesn't exist, so it sends the
request to tomcat even if there is no such file. Same underlying
cause: trying to dispatch based on parsing the URI instead of
using Apache's built in support for doing such things in a more
graceful and robust manner. Even more horrible is the fact that
mod_jk2 lets you enclose things in Location sections such as:
<Location "/*.jsp">
JkUriSet group ajp13:worker1
</Location>
...only it uses some horrible hacked up kludge to actually
parse the argument to the Location itself. Even though this
is a "Location" directive, because of mod_jk2's very odd
design the arguments are interpreted completely differently
from how Apache does, which leads to all sorts of chaos.
If I recall correctly, and I haven't checked for a few months, I
think there are some comments in the mod_jk2 code indicating that
support for using it as an Apache handler was removed because the
person hacking on it didn't understand why it is necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
