Sorry for being offline for 2 weeks :(
Sorry for the long post coming :((
I just now read the URL rewriting discussion. Although the discussion
seems to have come to an end, I find it worthwhile to actually add some
structure to it:
1) How to forward the URL
I already suggested a different forwarding default in my discussion 3
weeks ago. It was very close to what we ended up now and there are only
minor points to decide upon.
Since Tomcat does an additional decoding we have to prevent double
decoding in order to ensure correct URL mapping (independent of
security; an encoded percent is legitimate and needs to be handled
correctly as a percent at the end).
My original proposal included only reencoding percent signs (and maybe
spaces), because all other URL characters will not get double decoded by
Tomcat. If we don't trust this assumption, we could of course reencode a
lot more characters, like mod_proxy does. There will be some performance
penalty, because we could check pretty fast, if there are '%' or ' '
characters in the URL, and in case they are not, there's nothing to do
in my proposal. mod_proxy has a far longer list of chars to reencode and
so it doesn't do checking and instead runs the reencode loop directly.
The mod_proxy people have a good reason for encoding more characters:
the same code gets used for http, ftp and ajp forwarding. We could be
able to know, how the AJP connector works (do we?), so we could choose
to not reencode for instance characters above 127.
But Remy made a good point: different components might have different
decoding settings. I'm not sure, if this would apply to percent
encoding, but it gives my thoughts a litle warning.
At the moment there exist the following implementations:
- Compat: forward the decoded URI, security issues
- CompatUnparsed: forward the original request URI, breaks mod_rewrite
- Proxy: Reencode using mod_proxy "full" reencoding (save for semicolon,
i.e. URL session encoding), secure, adds some performance penalty
- Escaped: Reencode fully, safe but breaks URL encoded sessions,
- Minimal (the one I suggested): OK with mod_rewrite and sessions, a
little faster than Proxy, but maybe open to not yet thought upon
security threats, maybe also problematic if mod_jk and the backend use
different character sets (I don't know if AJP URLs would be binary
compatible for chars above 128 between mod_jk and the backend).
All in all I also vote for "Proxy" as the new default, maybe with a
little optimization by first checking the URL, if there are actual
characters from the reencoding set in there (in most cases there won't,
and we don't need to copy character by character).
I strongly vote for leaving the old options in there for 1.2. Because
for a long time default configurations had one of the old options as an
explicit parameter in them (so they are not using the default), we
should add a warning on startup, that the option is deprecated and
removing it will most likely make the configuration safer and more
interoperable with different environments. I would still allow using it.
2) Mladen's patch
The core idea of Mladen's patch was to check the URL against a known
classical way of breaking the combination mod_jk and Tomcat. Even after
fixing this breakage by re-encoding the URL before forwarding, I find it
worth of thinking about his patch.
Apache httpd for instance has a parameter to *allow* URLs with encoded
slashes which is by default *off*:
AllowEncodedSlashes Off
This disables some suspicious URLs stopps many of the standard break in
attempts.
So at least I see some reason for options to make the combination more
sensible to evil URLs. Encoded slashes as well as encoded backslashes or
encoded percent signs might be good candidates.
Since those URL parts can have legitimate use, those can only be
options, and one can discuss, if the default should be on or off. They
will help to harden the security.
Since mod_jk is for multiple web servers and maybe backends, there is
some reason to actually implement those checks, even if some
combinations might do it in front or behind mod_jk.
I would propose a check for encoded slashes, backslashes and encoded
percent signs, combined in one option "DenyUnsafeURL", which in 1.2 will
be off by default. Room for discussion here!
3) IIS, Netscape
We need to investigate, how we forward from IIS and Netscape. For IIS,
Mladen will know. Netscape uses decoded URL like Apache, so we'll switch
to the same handling as the new default in Apache.
Regards,
Rainer
Remy Maucherat wrote:
Mladen Turk wrote:
That's why I suggested to stop for a while and see all the possibilities.
We've talked about it for a while (see the length of this thread ...),
and I consider it is time to think over code: apply the proposed patch
which aims to harmonize with mod_proxy, and see what actual problems it
causes, if any. This means I am vetoing r544137 (the patch was an
emergency fix with some side effects, and needs to be replaced with a
proper implementation).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
