On 7/20/20 4:45 PM, Yann Ylavic wrote:
> 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.
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
