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 #10 from Guido Jäkel <g.jae...@dnb.de> ---
(In reply to Mark Thomas from comment #9)
> (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.

I fully agree: It's in the concern of the backend - in the same way it's in the
concern of the httpd frontend parser to deal with it.


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

Maybe this shows us the core problem and and a solution: "AllowEncodedSlashes"
must *replace* the encoded slash ('%2F') by a *distinguishable* special
representation and this special representation have to bee re-encoded later
(before any proxying by mod_jk or others) to the encoded slash.

Perhaps this special representation might be coded as an "illegal percent
encoding" using other digits as the hexadecimals, e.g. '%%/' 


Mark, may you please support me by a code snipped to check the actual value of
"AllowEncodedSlashes" within the mod_jk's jk_canonenc function or in the
context of it's caller?

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

Reply via email to