Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[Ruediger Pluem <rp...@apache.org>]

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

Regards

Rüdiger

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[jean-frederic clere <jf...@gmail.com>]

On 21/07/2020 06:51, William A Rowe Jr wrote:
> 
> 
> On Mon, Jul 20, 2020, 10:24 Ruediger Pluem <rpluem@apache.org 
> <ma...@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
>     <ma...@gmail.com>> wrote:
>      >>
>      >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem
>     <rpluem@apache.org <ma...@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

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[William A Rowe Jr <wr...@rowe-clan.net>]

On Mon, Jul 20, 2020, 10:24 Ruediger Pluem <rp...@apache.org> wrote:

>
>
> On 7/20/20 4:45 PM, Yann Ylavic wrote:
> > On Thu, Jul 16, 2020 at 10:31 PM Eric Covener <co...@gmail.com> wrote:
> >>
> >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem <rp...@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.

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[Ruediger Pluem <rp...@apache.org>]

On 7/20/20 4:45 PM, Yann Ylavic wrote:
> On Thu, Jul 16, 2020 at 10:31 PM Eric Covener <co...@gmail.com> wrote:
>>
>> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem <rp...@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.

Regards

Rüdiger

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[Yann Ylavic <yl...@gmail.com>]

On Thu, Jul 16, 2020 at 10:31 PM Eric Covener <co...@gmail.com> wrote:
>
> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem <rp...@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.

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[Eric Covener <co...@gmail.com>]

On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem <rp...@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.