On Thu, Jul 16, 2020 at 10:31 PM Eric Covener <cove...@gmail.com> wrote: > > On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem <rpl...@apache.org> wrote: > > > > > > > > On 6/24/20 1:27 PM, Eric Covener wrote: > > >> > > >> ProxyMappingDecoded is not needed anymore (and was removed). > > >> The mapping= tells mod_proxy at which stage ([pre_]translate) it > > >> should map the request path. > > > +1 > > > > > > > Getting back to an old topic. Shouldn't we have a directive similar to > > AllowEncodedSlashes that allows us to block URI's that contain > > URL fragments like /.; and /..; in order to avoid that someone plays > > silly games that bypass Location settings and RewriteRules > > that might be used with a servlet engine in the backend? Happy > > to have that set to a default that allows /.; and /..;. > > +, but I'd want the safer default.
Is this something we should care about outside the proxy mapping=servlet case? In the other cases, "/.;" and "/..;" are nothing but plain text (they won't be treated as "/." and "/.." on the filesystem AFAICT), so we could let them 404 normally. In the mapping=servlet case, servlet normalization is applied to r->[parsed_]uri (no "/.;" or "/..;" anymore), so Location/.. matchings use the same uri-path than the backend. This sounds a bit like we want to reject "/.;" or "/..;" for the servlet case but still accept "/." and "/.." unconditionally for the non-servlet case. So possibly we want a general "AllowPathTraversal" directive (off by default) for the core to allow/reject "." and ".." AND proxy mapping=servlet to extend it to "/.;" or "/.;" (and probably "/;" too since it's the same as "/.;" when MergeSlashes applies)? Regards; Yann.
