httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann <ylavic....@gmail.com>
Subject Re: Anonymizing 403 responses [Was: svn commit: r1799731]
Date Tue, 27 Jun 2017 08:00:31 GMT
On Tue, Jun 27, 2017 at 12:49 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Mon, Jun 26, 2017 at 5:43 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>> On Mon, Jun 26, 2017 at 5:34 PM, Yann <ylavic.dev@gmail.com> wrote:
>>
>>> What could be the "security blunders" with 404 vs 403?
>>
>> A 403 says "go away, you are denied". Hopefully modules are smart
>> about that.

Yes, and they can be smart about 404 too if that's the admin's choice.

>>
>> A 404 says "no such resource". Modules such as mod_speling try to
>> interpret what the user typed in an accommodating way, and come up
>> with something that aught to be served instead.
>>
>> In the particular example, /CON (device) might be interpreted as /.conf
>> (file). But if the admin/author is attentive, they deny access to .conf and
>> the remap attempt fails.

Provided /.conf access is granted, I don't see where the security
issue is (the user could request it directly). So either mod_speling
bypasses the access checks (I don't think it's the case) and that's
what I called its potential bug, or it's an "administrative" bug.

>
> FWIW mod_speling is well-understood to reveal such 'hidden files'.
> Even if we fixed the specific case for /con (device) remapping, all
> the user would have to do is attempt to access ".con" (no file found)
> to discover .conf in that directory, if it isn't prohibited.

For something like "/access/to/prn/sites", dunno if mod_speling is
pervert enough to notice the typo :p

>
> I trust that both presenting CHR files as 403 is not an issue, and that
> mod_speling's behavior is correct so far as it goes if users choose to
> deploy it. But it seems like there should be some deterministic way
> to reject non-file or other entities as not-found without other modules
> attempting to 'just fix it.'

I don't think the current behaviour is an issue, but it looks not
enough correct.
It seems that one can create a "regular" file or directory containing
such "reserved" word (by using UNC paths, but I don't know enough
about Windows to say if it's really the case and from which version).
So we (or APR) should be able to determine whether it really exists or
not, and/or its access is truly denied by the OS (or httpd), and
return the correct 4xx no?


Regards,
Yann.

Mime
View raw message