httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Riggs <apache-li...@riggs.me>
Subject Re: *Match, RewriteRule POLA violation?
Date Fri, 01 May 2015 19:01:49 GMT
> On 1 May 2015, at 10:52, André Malo <nd@perlig.de> wrote:
> 
> * Niklas Edmundsson wrote:
> 
>> On Thu, 30 Apr 2015, Yann Ylavic wrote:
>>> On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs <apache-lists@riggs.me> 
> wrote:
>>>> Thanks, Yann. I remember looking at this code before. The question
>>>> remains, though: Is it currently "wrong"? Does it need to be "fixed",
>>>> or was this distinction made intentionally? Is there a specific use
>>>> case that requires the regex-matching directives to not get
>>>> slash-normalized URIs?
>>> 
>>> I would like it to be fixed, non leading "/+" is equivalent to "/",
>>> this would break very few (if any) cases IMHO, and may even unbreak
>>> more ones .
>> 
>> +1
>> 
>> I would expect Location and LocationMatch using the same uri for
>> comparison.
> 
> Hmm, that assumption is wrong by definition. Location always matches a 
> prefix (a part of a parsed/unparsed url), while LocationMatch always 
> matches the complete URL.

We need to be careful on that phrasing. LocationMatch *can* match the complete URL if it is
anchored at both ends. By default, though, it will match anywhere in the URL if it is unanchored,
and it can (with the '/+' we are discussing here) behave just like Location and match a prefix
if it is only anchored at the beginning.


>> I would actually go so far as the current state might 
>> warrant a CVE for being a hidden security risk that might cause
>> inadvertent information exposure.
> 
> It *is* documented right here, btw: 
> http://httpd.apache.org/docs/2.4/mod/core.html#location
> 
> (found it, eventually...)

Yay! I knew I had read it somewhere. Good find!

However, that documentation is actually not correct. This is not true: "For example, <LocationMatch
\"^/abc\"> would match the request URL /abc but not the request URL //abc." Based on all
of my tests, the leading slash *is* collapsed in the *Match and RewriteRule directives. Subsequent
slashes after the first are not.

So, it is documented, but is there a compelling use case for this? When would someone actually
need to match against the multiple slashes (unless it's some really strange hack someone has
implemented)? The only thing I can think of is that maybe you want to force a redirect to
remove multiple slashes, but couldn't a directive in mod_alias(?) maybe handle that if deemed
necessary?

Also, yes it is documented, but when I brought it up at a hackathon table full of long-time
committers at ApacheCon, no one knew about it, and I had to make an example. This says to
me says that maybe it's unexpected behavior and a potential security risk as both Niklas and
Ruggeri have suggested. That's why I brought it up in the first place.

And so the questions still remain: Right or wrong? Change it or leave it? Expected or unexpected?
Security risk or user/configuration error?

The world may never know... ;-)

I may go ahead and write up a patch this weekend to change them all (*Match and RewriteRule)
and then we can all debate it over on bugz too!


Mime
View raw message