https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |WONTFIX
--- Comment #9 from Mark Thomas <ma...@apache.org> ---
(In reply to Guido Jäkel from comment #8)
> To point this out: You see a "directory traversal" issue IF
> AllowEncodedSlashes is OFF?
Yes.
> Maybe here, in this function. But then, an URL
> containing slashes will rejected by the http anyway.
JkMount /examples/*
URI /examples/foo/..%252F../docs
Now gets passed as /examples/foo/..%2F../docs
What happens then depends on what back-end the URI is passed to and how that
back-end is configured. Some will reject it. Some will process it. For those
that process it, this is a directory traversal.
> Yes, this is the core point. I'm not familiar with this software, but (IMHO)
> there CANNOT a '%252F' appear here.
I see no reason why a user agent would be unable to present "%252F". Keep in
mind that any solution has to be completely generic, not specific to any one
use case and there may well be an ID scheme somewhere where a valid, unencoded
ID includes the sequence "%2F" which would then be encoded as "%252F" when it
appears in the path.
> > 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.
What you are asking for is logically impossible. If mod_jk sees the sequence
"%2F" it has no way to determine if this is the result of decoding "%252F" or
not decoding "%2F". Therefore it cannot correctly reverse the encoding.
--
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
