It was thus said that the Great Hugh E Cruickshank once stated:
> From: Nick Kew Sent: September 15, 2008 19:43
> >
> > On 16 Sep 2008, at 02:44, Hugh E Cruickshank wrote:
> >
> > > Right now if someone were to attempt to access these subdirectories
> > > (i.e. http://www.example.com/cgi-bin) they would receive a 403
> > > Forbidden error message. Unfortunately this is not quite acceptable
> > > to the IBM Rational AppScan utility which recommends that a 404
> > > Not found error should be issued.
> >
> > I suspect you're misreading your AppScan.
>
> That is a good possibility.
>
> > It's warning about potentially exposing your filesystem information.
>
> Most probably.
>
> > But there's nothing secret about a directory containing a web-facing
> > application!
>
> That may be the case but their recommendation is still: Issue a "404 -
> Not Found" response status code for a forbidden resource, or remove it
> completely.
I don't necessarily agree with that advice either because if you don't
specify the 404 for all cases, you'll *still* reveal "precious" information
about your secret filesystem (and "security through obscurity" is worse than
"no security").
But, if you want to do it, then you'll need to do the following *for every
directory under your webroot*:
RedirectMatch 404 ^/$
RedirectMatch 404 ^/path$
RedirectMatch 404 ^/path/$
RedirectMatch 404 ^/path/to$
RedirectMatch 404 ^/path/to/$
RedirectMatch 404 ^/path/to/directory$
RedirectMatch 404 ^/path/to/directory/$
The reason for both? Well, as you have it configured right now (with the
403 response), if I go to <http://www.example.com/cgi-bin>, Apache will see
that as a directory, and send back a 301 response, redirecting me to
<http://www.example.com/cgi-bin/>, which my client will then attempt to get,
and then get the 403 response (Hmm ... I would actually test that first, but
that's the normal process if you did allow index views).
You might be tempted to try this with one line, but if you screw it up,
you may end up with your entire website 404.
But even if you do this, there may be unintended consequences with
reguards to search engine optimization. Saying, for instance, that
<http://www.exmaple.com/path/> is not found, it might not bother indexing
anything else below that point. I'm not saying that *will* be the case; I'm
saying that *might* be a case.
The 403 says, "you can't see this" which is different from a 401 ("you
can't see this because you didn't have the right credentials") and a 404
("I have no idea what you asked for") and a 410 ("This is gone. This is an
ex-page. This page has joined the choir invisible"). By saying "404"
instead of "403" you're lying to the client program about what it can and
can't reference.
I'm dubious about the advice begin given, and without a reference to some
company actually being exploited or hacked because information about how the
site was laid out on the filesystem of the webserver, I would strongly
disregard such advice (on the princple of "show me---and no hand-waving
about some possible attack"). I have a bit more to say about such "security
audits" at <http://boston.conman.org/2005/12/21.1> [1]
-spc (Hope this helps)
[1] The advice taken to an extreme would be to cut the network cable and
power to the web server, smash it to pieces, embed the fragments in
concrete and dump in the middle of the Pacific ocean, then nuke the
site from orbit---it's the ony way to be sure).
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|