You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Hugh E Cruickshank <hu...@forsoft.com> on 2008/09/16 03:44:04 UTC
[users@httpd] Directory hiding
Apache 2.0.46 on RHEL3.9
Hi All:
I am attempting to determine if there is a method of "hiding" the
subdirectories on our web server. I have spent the better part of
the day doing Google searches without coming up with anything that
would seem to work.
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 did find one suggestion. So I tried adding:
<DirectoryMatch cgi-bin>
order allow,deny
deny from all
</DirectoryMatch>
but this did not work and it would not allow our application to run
either.
Any suggestions would be greatly appreciated.
TIA
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Directory hiding
Posted by Hugh E Cruickshank <hu...@forsoft.com>.
From: André Warnier Sent: September 16, 2008 15:44
> Hugh E Cruickshank wrote:
> [...]
> > 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.
> Might your client appreciate if your own due diligence pushed you to
> inform them that their security consultant is telling them nonsense,
> and that it might be time to upgrade it ?
> ;-)
That may well be the case. This particular client is still in the pre-
sales phase and I would be thrashing around in uncharted waters. It
would not be very politic of me to say point out that their security
consultant does not know what they are talking about when it turns
out that it was done by an internal department or worse yet the
president's brother-in-law (or some other such dubious qualification).
I will probably end up saying something about it not being a very
serious threat but we are such good guys we fixed it anyway. Well
maybe not that exactly, I will let the sales people spin it to their
hearts content.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Directory hiding
Posted by André Warnier <aw...@ice-sa.com>.
Hugh E Cruickshank wrote:
[...]
> 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.
Might your client appreciate if your own due diligence pushed you to
inform them that their security consultant is telling them nonsense, and
that it might be time to upgrade it ?
;-)
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Directory hiding
Posted by Hugh E Cruickshank <hu...@forsoft.com>.
From: Hugh E Cruickshank Sent: September 16, 2008 15:32
> 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.
> >
[snip]
> > 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.
>
That worked like a charm.
Much thanks to all who replied.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Directory hiding
Posted by Hugh E Cruickshank <hu...@forsoft.com>.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Directory hiding
Posted by Sean Conner <sp...@conman.org>.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Directory hiding
Posted by "J. Greenlees" <li...@jaqui-greenlees.net>.
Nick Kew wrote:
>
> On 16 Sep 2008, at 06:57, Hugh E Cruickshank wrote:
>
>> 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.
>
> Either they're wrong or you're misreading.
>
> But I can see what's happening. It's "chinese whispers", starting from
> the CIS benchmark. Most likely someone along the way (IBM's tech
> writer's boss or somesuch) insisted that a meaningful explanation
> would be too difficult for their lusers, and either didn't understand or
> didn't care that it's misleading.
>
> Security by Cookery. BTDT. I can feel a blog entry coming on.
>
~chuckle~
Technically, cooking is following a detailed set of instructions, one
set for each item being cooked, so it's not quite as bad as it sounds.
I don't disagree with the conclusion in this particular case, hiding
filesystem structure in the documentroot is not an improvement in security.
I'm always concerned with security issues, but it's in the app code and
data verification that I see as being where to focus my attention. At
least until such time as updated underlying technologies are implimented
to address the security issues.
Since the internet was built at a time and in an environment where
security wasn't a concern at all, the core technologies need to be
rebuilt with security as a priority. That would probably impact the HTTP
Server and many other projects, requiring a lot of work to have them
function with the new system(s) properly.
Jaqui
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Directory hiding
Posted by Nick Kew <ni...@webthing.com>.
On 16 Sep 2008, at 06:57, Hugh E Cruickshank wrote:
> 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.
Either they're wrong or you're misreading.
But I can see what's happening. It's "chinese whispers", starting from
the CIS benchmark. Most likely someone along the way (IBM's tech
writer's boss or somesuch) insisted that a meaningful explanation
would be too difficult for their lusers, and either didn't understand or
didn't care that it's misleading.
Security by Cookery. BTDT. I can feel a blog entry coming on.
--
Nick Kew
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Directory hiding
Posted by Hugh E Cruickshank <hu...@forsoft.com>.
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.
> Having said that, rtfm ErrorDocument for one way to do what you ask,
> if it's for some ignorant PHB's box-ticking exercise.
Colour me stupid but as far as I can tell ErrorDocument only provides
for the replacement of the text of a message. I can not see how it can
be used to force a 404 instead of a 403.
Thanks for your response anyway.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Directory hiding
Posted by Nick Kew <ni...@webthing.com>.
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. It's warning about
potentially
exposing your filesystem information. But there's nothing secret about
a directory containing a web-facing application!
Having said that, rtfm ErrorDocument for one way to do what you ask,
if it's for some ignorant PHB's box-ticking exercise.
--
Nick Kew
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org