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

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

Reply via email to