https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Guido Jäkel <g.jae...@dnb.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |FIXED
--- Comment #8 from Guido Jäkel <g.jae...@dnb.de> ---
(In reply to Mark Thomas from comment #7)
Thank you a lot for discussion!
> The proposed patch enables a directory traversal vulnerability with the
> default configuration. Therefore, it can't be applied in its current form.
>
> Even if the patch's behaviour is restricted to only be enabled with:
>
> AllowEncodedSlashes NoDecode
> [...]
To point this out: You see a "directory traversal" issue IF AllowEncodedSlashes
is OFF? Maybe here, in this function. But then, an URL containing slashes will
rejected by the http anyway. Please explain, if i'm wrong with this.
> mod_jk needs to differentiate between %252F and %2F in the original URI to
> correctly re-encode the processed (mod_rewrite etc.) URI which it is not
> going to be able to do in all circumstances. The problem is that both "%252F
> and "%2F" are identical in decoded form if "%2F" is not decoded and there is
> no way to tell them apart.
Yes, this is the core point. I'm not familiar with this software, but (IMHO)
there CANNOT a '%252F' appear here. And if, then it's garbage-in because there
incoming URL can be expected to be fully decoded here.
If you think (or even know), this CAN and is valid -- e.g. for some other part
of the URL than the path elements section, THEN my suggestion may be extended
to have the "syntactical knowledge" to act only on path elements.
> The only viable option is to use:
>
> JkOptions +ForwardURICompatUnparsed
>
> which has the significant disadvantage that mod_rewrite etc. cannot be used.
... and is a non-option for us because we need exactly this other things, too.
And in the meanwhile, it's urgent.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
