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