View previous topic :: View next topic |
Author |
Message |
mlnzigzag n00b

Joined: 19 May 2009 Posts: 58
|
Posted: Fri Nov 05, 2010 10:30 am Post subject: Securing Apache: Return 404 instead of 403 with mod_rewrite |
|
|
Hi people, i'm basically a noob of mod rewrite.
I would like to write a rule that matches any 403 error and rewrites it as a 404.
I'm able already to do that for a specific directory with such a rule:
Code: | RewriteRule ^/WebSite/img$ /error/404_403.php
RewriteRule ^/WebSite/img/$ /error/404_403.php |
/error/404_403.php is purposely a non-existant file
That rule will return a 404 instead of the 403 Forbidden for the existing directory
as you can see i had to write two rules with and without the ending / to handle both cases.
And here you can see a curl output of the rule above, as you can see the server returns a 404 Not Found, that is my goal:
Code: | > GET /WebSite/img/ HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> Host: *******.net
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Fri, 05 Nov 2010 10:05:40 GMT
|
What i would like to write is one global rule that rewrites any 403 forbidden to a 404 not found.
Please note that is not enough to serve custom error pages, such as:
Code: |
ErrorDocument 403 /error/existing_404_403.php
ErrorDocument 404 /error/existing_404_403.php |
with an existing and proper 404 error page, as with the appropriate curl flags (and with many other tools) a remote attacker will still be able to see the true http response, wich will still be 403, even if the disaplyed html is a 404 Not Found custom error page:
Code: | < HTTP/1.1 403 Forbidden
< Date: Thu, 04 Nov 2010 14:42:52 GMT
< X-Powered-By: PHP/5.2.10
< Content-Length: 202
< Connection: close
< Content-Type: text/html; charset=ISO-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
|
Please be patient with my poor english
I'm not very sure if this thread should be in Security, the moderators will please take care of that.
Thanks a lot for any kind of help
Marco |
|
Back to top |
|
 |
aCOSwt Bodhisattva

Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Fri Nov 05, 2010 11:17 am Post subject: Re: Securing Apache: Return 404 instead of 403 with mod_rewr |
|
|
mlnzigzag wrote: | What i would like to write is one global rule that rewrites any 403 forbidden to a 404 not found. |
Well, I do not know the answer to your exact question.
What I do personally in order to achieve what you wish in final with a single rule is that :
1/ I give special names to the files / directories I want to protect. Let's say their names all begin with a "."
2/ RedirectMatch 404 ".*\/\..*" does the trick. |
|
Back to top |
|
 |
mlnzigzag n00b

Joined: 19 May 2009 Posts: 58
|
Posted: Fri Nov 05, 2010 11:21 am Post subject: Re: Securing Apache: Return 404 instead of 403 with mod_rewr |
|
|
aCOSwt wrote: | mlnzigzag wrote: | What i would like to write is one global rule that rewrites any 403 forbidden to a 404 not found. |
Well, I do not know the answer to your exact question.
What I do personally in order to achieve what you wish in final with a single rule is that :
1/ I give special names to the files / directories I want to protect. Let's say their names all begin with a "."
2/ RedirectMatch 404 ".*\/\..*" does the trick. |
Thanks mate, that actually would solve the issue, but how would you apply such a change in a production environment, where 50 vhost based sites will have to change every path to the linked resources?
I really wish there is something that can be done with mod_rewrite or any other apache mod to workaround this.
Many thanks for your reply
ML |
|
Back to top |
|
 |
aCOSwt Bodhisattva

Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Fri Nov 05, 2010 11:39 am Post subject: Re: Securing Apache: Return 404 instead of 403 with mod_rewr |
|
|
mlnzigzag wrote: | ...how would you apply such a change in a production environment, where 50 vhost based sites will have to change every path to the linked resources?  |
Gee ! I understand better your problem
Hmmm... Nevermind... Fire the change... you'll tell it's aCOSwt's fault !  |
|
Back to top |
|
 |
Hu Administrator

Joined: 06 Mar 2007 Posts: 23333
|
Posted: Sat Nov 06, 2010 2:42 am Post subject: |
|
|
What value does this serve? How does forging a 404 in place of a 403 improve security? |
|
Back to top |
|
 |
desultory Bodhisattva


Joined: 04 Nov 2005 Posts: 9410
|
Posted: Sat Nov 06, 2010 8:58 am Post subject: |
|
|
mlnzigzag wrote: | Please note that is not enough to serve custom error pages, such as:
Code: |
ErrorDocument 403 /error/existing_404_403.php
ErrorDocument 404 /error/existing_404_403.php |
with an existing and proper 404 error page, as with the appropriate curl flags (and with many other tools) a remote attacker will still be able to see the true http response, wich will still be 403, even if the disaplyed html is a 404 Not Found custom error page: | Not enough, but it is close to a working solution. Create a directory for error handlers, set the global 404 and 403 handlers to a fully qualified URL pointing into that directory at some nonexistent resource, set the 404 handler for that directory to default or some other handler that does actually exist.
mlnzigzag wrote: | I'm not very sure if this thread should be in Security, the moderators will please take care of that. | It pertains to networking and security, so it would seem to fit.
Hu wrote: | What value does this serve? How does forging a 404 in place of a 403 improve security? | It provides a degree of security through obscurity by not providing potential attackers with an easy way to determine where files that they are not supposed to have access to are located. |
|
Back to top |
|
 |
aCOSwt Bodhisattva

Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Sat Nov 06, 2010 9:01 am Post subject: |
|
|
Hu wrote: | What value does this serve? How does forging a 404 in place of a 403 improve security? |
In a way that it does not give any clue.
HTTP403 does give a clue : You get a correct path but you do not get the right perms. => What you are looking for and should not see is actually here !
HTTP404 from the specs just say : There is nothing there !
Which, in a first step will mislead the hacker-n00b and confuse the Tux's little helper who knows that things can be disguised but then cannot deduce if the path is wrong or the perms are wrong.
EDIT : Desultory is quicker for comiting ! and definitely the most clever:
desultory wrote: | Create a directory for error handlers, set the global 404 and 403 handlers to a fully qualified URL pointing into that directory at some nonexistent resource |
Simply clever ! |
|
Back to top |
|
 |
aCOSwt Bodhisattva

Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Sat Nov 06, 2010 9:35 am Post subject: |
|
|
aCOSwt wrote: | Simply clever ! |
Well... only clever I mean...
BTW... If I understand well your solution, this should not confuse the hacker-apprentice because there will actually be an initial HTTP403, that will in its turn trigger an HTTP404 right, but the initial HTTP403 is... Hmmm... how would I say... hmmm... see-able !
Last edited by aCOSwt on Sat Nov 06, 2010 9:54 am; edited 1 time in total |
|
Back to top |
|
 |
desultory Bodhisattva


Joined: 04 Nov 2005 Posts: 9410
|
Posted: Sat Nov 06, 2010 9:51 am Post subject: |
|
|
The 403 would 302 to a 404. |
|
Back to top |
|
 |
aCOSwt Bodhisattva

Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Sat Nov 06, 2010 9:53 am Post subject: |
|
|
desultory wrote: | The 403 would 302 to a 404. |
You are right! I had summarized...
However... these transitions are see-able indeed ! |
|
Back to top |
|
 |
desultory Bodhisattva


Joined: 04 Nov 2005 Posts: 9410
|
Posted: Sat Nov 06, 2010 9:56 am Post subject: |
|
|
They are visible but they are entirely consistent between 403 and 404, as both 302 to a 404, wrapping the whole thing behind a front end proxy could make it appear to directly 404 to a client, but by that point there must be a cleaner solution. |
|
Back to top |
|
 |
mlnzigzag n00b

Joined: 19 May 2009 Posts: 58
|
Posted: Sat Nov 06, 2010 10:23 am Post subject: |
|
|
Hu wrote: | How does forging a 404 in place of a 403 improve security? |
Because returning a 403 Forbidden returns two informations to the remote attacker:
1) the access to the file/folder is restricted
2) the file/folder EXISTS
Thus, the more 403 the remote attacker gets, more informations he gathers about the filesystem structure.
This is beyond the PCI-DSS compliance, i know it's something maniac, but some customers pretend this type of hardening!
I'll tell you later the exact Security Policy they want to meet, i can't remember it right now.
ML |
|
Back to top |
|
 |
mlnzigzag n00b

Joined: 19 May 2009 Posts: 58
|
Posted: Sat Nov 06, 2010 10:30 am Post subject: |
|
|
desultory wrote: | They are visible but they are entirely consistent between 403 and 404, as both 302 to a 404, wrapping the whole thing behind a front end proxy could make it appear to directly 404 to a client, but by that point there must be a cleaner solution. |
Thanks a lot guys for your interest in my thread.
I'm gonna make my tests on monday, and will post the results ASAP.
Thank you very much!
ML |
|
Back to top |
|
 |
mlnzigzag n00b

Joined: 19 May 2009 Posts: 58
|
|
Back to top |
|
 |
aCOSwt Bodhisattva

Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Sun Nov 07, 2010 9:01 am Post subject: |
|
|
desultory wrote: | They are visible but they are entirely consistent between 403 and 404, as both 302 to a 404 |
<trolling>
Consistence ?... Hmmm... Yes indeed !
If, as anybody can legally do, see a 302 -> 404, then... OK, there is some ambiguity...
Either the sysadmin is a moron or... he is pulling my leg !
</trolling>
<practicalling>
I do not think devoting the job to the proxy is an acceptable solution. Googling "tunisia fake 404" returns hundreds of suggestions on how to bypass a proxy faking 404s for whatever reasons.
mlnzigzag was looking for a solution with mod_rewrite, I initially thought mod_headers but, as far as I tried, it seems to imply many undesirable side effects because, as far as I undesrtood, it acts either on 2** statuses only or on everything, which leads to a significant amount of work.
</practicallling>
<intellectualling>
... then... why not... YESSSS !
THE solution is through a non-parsed headers script ! With a nph-* script, to the simple cost of being obliged to define the entire header yourself, you will send the 403 with an authentic 404 http header.
</intellectualling>
</dreaming>
vi apache_sources
:g/403/s//404/g
ZZ
</dreaming>
<Off-Topicing-Moral>
BTW : I am convinced that either mlnzigzag's systems face true hackers who are likely to easily bypass the proxy and of course not get mislead by redirections, in which case a nph-* script is THE solution...
OR... as his last post suggests,
it is only a matter of internal policy... in which case... it is just too stupid.
It is well known that policies are reinforced by standards/common-sense. A policy infringing standards/common-sense just weakens itself !
And the standard/common-sense is : serve your pages as what they are !
Well... anyway... I believe it is not in mlnzigzag's power to discuss that kind of things with his bosses... => Do what desultory advised !
His solution is simple, aesthetic and answers your rolling-over issue.
After all, mlnzigzag you seem asked for something... period. Not necessarily something... efficient !
</Off-Topicing-Moral> |
|
Back to top |
|
 |
desultory Bodhisattva


Joined: 04 Nov 2005 Posts: 9410
|
Posted: Sun Nov 07, 2010 9:55 am Post subject: |
|
|
aCOSwt wrote: | <intellectualling>
... then... why not... YESSSS !
THE solution is through a non-parsed headers script ! With a nph-* script, to the simple cost of being obliged to define the entire header yourself, you will send the 403 with an authentic 404 http header.
</intellectualling> | Using bouncing redirects was meant only as a way to do something functionally equivalent while only depending on core modules, if scripting is an option, nph scripts are indeed the correct solution. |
|
Back to top |
|
 |
|