From: Sean Conner Sent: September 15, 2008 23:36
> It was thus said that the Great Hugh E Cruickshank once stated:
> >
> > 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").
I hear you but the client's security consultant (or whatever) is
making the recommendation based on the software's report and the
client is exercising due diligence by reporting the issues to us and
we are trying to keep the client satisfied. If I can accomplish that
without undue effort then I will. client's tend to appreciate the
effort.
> 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/$
>
[snip]
I will give that a shot tonight.
> 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.
Been there, done that with the 403 for the whole site on a previous
attempt.
> 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.
This is not a significant consideration in our case as the entire site
is one application that is restricted only to our clients. Search
engine indexing is not applicable nor desired.
> 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
> ivisible"). By saying "404" instead of "403" you're lying to the
> client program about what it can and can't reference.
All true but our clients are trying to use a web based application
not a set of web pages so I can not see them having a whole lot of
interest in our web page structure.
> 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 agree but it is not harmful so if I can satisfy the client without
too much effort then I will.
> I have a bit more to say about such "security audits" at
> <http://boston.conman.org/2005/12/21.1>
I will have a look at that.
> -spc (Hope this helps)
Every little bit helps but I will try out your suggestion later this
evening at let you know.
Thanks for the response.
Regards, Hugh
--
Hugh E Cruickshank, Forward Software, www.forward-software.com
---------------------------------------------------------------------
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
|