Jul 23, 2020, 1:56 AM
Post #32 of 32
(506 views)
Permalink
On 21/07/2020 06:51, William A Rowe Jr wrote:
>
>
> On Mon, Jul 20, 2020, 10:24 Ruediger Pluem <rpluem@apache.org
> <mailto:rpluem@apache.org>> wrote:
>
>
>
> On 7/20/20 4:45 PM, Yann Ylavic wrote:
> > On Thu, Jul 16, 2020 at 10:31 PM Eric Covener <covener@gmail.com
> <mailto:covener@gmail.com>> wrote:
> >>
> >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem
> <rpluem@apache.org <mailto:rpluem@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.
>
> I think for the default handler this is no problem. As you state
> such URL's likely produce just a 404 and we are done.
>
> > 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.
>
> But only if you have an appropriate ProxyPass in place. With
> RewriteRules this does not work.
> Hence I think we need an additional mechanism to handle this in case
> of no ProxyPass directives.
> I still fail to see a real use case for /..; and /.; segments. Hence
> I think denying them should
> be possible with a simple option without the need for a ProxyPass
> directive or an additional
> RewriteRule. This would also keep path parameters in other segments
> as they are.
> As said I am even happy if the default of this directive would keep
> the current behavior.
>
> > 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)?
>
> I don't want to allow/deny '.' and '..'. Without path parameters I
> just want to remove ('.') / shrink them ('..') without going
> past root like we do today.
>
>
> From the beginning of this dialog, that isn't the function of an HTTP/1
> proxy. We have no business in that PER THE SPECS.
>
> I don't understand why the Tomcat project and other servlet providers,
> after given evidence they broke the spec, and downgrade of their
> reservations of the ;params logic out of the URI spec, keep insisting
> the behavior is necessary for the HTTP transport providers to consider.
>
> I don't understand why, Ruediger, some keep defending the .; or ..; as a
> normative acceptable path element, and refuse to consider the idea that
> every such occurance is malicious, without evidence of a single legit
> application of that formation.
>
> If you don't want to let them slide, we *could* deny \.;.* and \.\.;.*
> by default. Or we already *can* when ajp users would like to add rewrite
> rules.
mod_proxy_http and mod_proxy_ajp behave the same way, mod_jk will return
DECLINED and end normally in 404.
; in the URI is for a parameter like ;foo=bar I was first just
suggesting to return 400 in possibly "unsafe" ..;/ URI using a parameter
to prevent "regressions", but I think we ended looking to something too
complex :-(
>
>
>
--
Cheers
Jean-Frederic