Can I hide a directory and return error 404?

[mavreela]

I have an includes directory that I want to protect. I can easily deny access in .htacess but this returns an error 403 - no one can get in but they know it is there. Detecting the presence of a suitably named directory could reveal the underlying architecture and make the site vulnerable to known bugs and vulnerabilities with it. By instead returning an error 404 message anyone trying to break in would stop that line of attack and move on.

That is the hypothetical situation I am wishing to potentially avoid anyway. But how can I do this?

The only solution I can think of is have each of the include files (which are php) include code to detect when they are being loaded and if so return the 404 status themselves. This seems rather messy though. Is there anything I can add in .htaccess to instead simulate this effect?

Thanks,

Michael.

[Gwaihir]

An includes folder as in PHP-includes? If so, just move it out of the web-root.

If not, then I think any simple block you set up would block the legimate use intended as well.

[mavreela]

Proper use would not be blocked because Apache (and so php) would will be able to access the file locally, it would just be connections through Apache (over that the web) that would fail.

Putting files outside the web root is a good idea but a lot of open source CMS, bulletin boards etc. do not support this. At least not without having to modify every file and at very upgrade and patch.

Anyway I have found an answer through trying something out which to my surprise worked. In .htaccess just add "Redirect 404 /includes". I only tried this because "Redirect gone file-path" returns an error and does not take a parameter not expecting much so am quite pleased, and it is documented behaviour too.

Not sure why I had not noticed earlier as I did try using Redirect to something nonexistent to force a not found error, but this instead gave me a 500 configuration error so I gave up on that approach. Looking back at the Apache documentation:

"Other status codes can be returned by giving the numeric status code as the value of status. If the status is between 300 and 399, the url argument must be present, otherwise it must be omitted. Note that the status must be known to the Apache code (see the function send_error_response in http_protocol.c)."

It in inexcusable I missed that having read it several times already, it would certainly have saved me a lot of time trying to find someone else who had tried to achieve the same effect.

I am surprised this technique is not used more often as it works (accessing the directory or any file within the directory returns a 404 while any pages including files contained within still work) and provides an extra level of security. It would not take long to work out what the presence of a fusion_includes directory means about a site, for example.

Only caveat is that any .htaccess file within the "hidden" directory will still override the Redirect so if you have an .htaccess file within it to deny access it will still return an error 403 (Not Allowed) so this would need to be removed.

Well I hope this helps someone else. You could even use this to redirect specific files like "Redirect 404 /config.php".

Michael.

[Ron]

I might create an index.php file and have it return a 404.

<?php
header("HTTP/1.0 404 Not Found");
?>

Or something like that.

[JPC-Greg]

Ron that will not stop people from accessing the files in that directory. Id use the redirect Mavreela suggested but thats just me.

[Ron]

True. I assumed the person wanted to do what they had stated in their topic title, and didn't read their posts carefully enough I guess.

I would like to know what application creates an "includes" directory and puts files in it that contain "main" sections, that is, areas of php code that are not part of any function.

For instance a file by the name of "fake_functions.php" within an includes directory:

<?php
// * ***********************************************
// *
// *            fake_funtions.php
// *
// * Designed to be a proof of concept
// * No real functionality here:
// * secret phrase:  "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
// *
// *************************************************
function fake_function1($foo)
{
// *************************************************
// *
// * fake_function1
// * Part of the proof of concept
// * No functionality here, either
// * secret phrase:  "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
// *
// *************************************************
//this is just a fake function
printf("hello %s<br>\n",$foo);
}
?>

would simply return a blank page if pointed to from a browser.
I even put comments in the "main" area.

Is there any way for a browser or any other external application to get that fake_function1($foo) to execute (on it's current machine), or to get Apache to return the code instead of attempting to execute the main-less file?
Here's that file to test for it:
http://69.73.178.5/includes/fake_functions.php

Anyone (without root privileges, Jag ) care to tell me what the secret phrases are?
I've also placed another file in that directory -- anyone (without root privileges, Jag ) want to tell me the filename?

Big hint: It starts with the letter "n".

[Spathiphyllum]

...Anyway I have found an answer through trying something out which to my surprise worked. In .htaccess just add "Redirect 404 /includes". I only tried this because "Redirect gone file-path" returns an error and does not take a parameter not expecting much so am quite pleased, and it is documented behaviour too...

Did you try "Redirect 410 file-path"? Without reading more documentation, maybe the directive only wants digits here.

[mavreela]

Ron, you are correct that pretty much all php include files will return a blank page. A hacker though would know though that if they are getting a blank page (or more accurately the 200 OK status code) instead of an error 404 Not Found then they know that the file exists.

If you wanted to hack a site then by checking to see whether certain files exist could be enough to alert you to what application is being used, and so which exploits you can take advantage of.

Granted it only offers a weak level of security and should not be used in place of real measures to secure a site, but obfuscation provides that little bit of extra protection and makes the hackers job that little bit harder, for what is very minimal effort. Why give them information they do not need?

Incidentally with regard to "fake_functions.php" some people use a .inc extension on include files, and unless the server is configured to parse these as php files also they would be returned as plain text (I am not sure how things are configured on Jaguar). A file with a .php extension though should be safe unless something catastrophic happens with php/Apache, in which case the server would probably not server anything anyway.

But one possible vulnerability is if a script exists that returns a file (say with a URL like http://mysite.com/site.php?about.html - which surprisingly some sites use) and which does not have appropriate restrictions then it would locally load and display the file, bypassing the php parser and so displaying the contents. If the hacker knows the file exists this can be exploited, if they are told the file does not exists they are unlikely to try.

Spathiphyllum - I did not try using numbers but 'gone' was one of the listed keywords in the Apache documentation. As I found the answer I was looking for I am pretty happy now.

Michael.

[Ron]

If the script that you're using is so popular that hackers are lined up to find sites using it to exploit, then I don't think that hiding your include files is going to help much.

I'd guess there'd be tons of other clues, like the formatting of your pages, or the names of the non-hidden script files, like "viewtopic" or "modcp" or the like, to refer to phpBB. Are you going to sed or rewrite the entire app to hide the exposed filenames?

I think you're "barking up the wrong tree", spending any amount of time developing a piece of a security-by-obscurity scenario, but that's just me. I've been wrong before, and I've barked up a lot of wrong trees too. Sometimes they look really interesting as an exercise in barking (Which is why I looked into this in the first place.)

I HAVE seen servers here (but a long long time ago) return cgi files as text. It would occur in the middle of browsing the site... a page's source would show up as text, then on reload it would be fine. I wonder if they were working on the apache files at the time, but it was interesting.

Good luck.