Telling between a "natural" HTTP 404 and a PHP Generated one

So I have a file that should never be accessed by a user directly, but included in another PHP file. If the file is called directly, it generates a HTTP开发者_StackOverflow中文版 Status 404 Not Found to trick a possible attacker that such file doesn't exist. However, if the hacker could tell that the 404 was generated by PHP or is not "natural" then the whole point of the header would be lost. So is it possible to tell whether the 404 was generated by the server naturally (because the file really doesn't exist) or by a PHP code?

PS: I know this question might seem pretty weird lol

A smart attacker would check the raw status headers and look for any discrepancies that might indicate if something was a "natural" 404 or not.

For example, the version of Apache on my server sends back the following headers if you request a file that's not there

HTTP/1.1 404 Not Found
Date: Thu, 06 Jan 2011 18:10:57 GMT
Server: Apache/2.2.17
Content-Type: text/html

However, if I setup a PHP page to send back a 404 header, my server sends back the following headers

HTTP/1.0 404 Not Found
Date: Thu, 06 Jan 2011 18:10:48 GMT
Server: Apache/2.2.17
Connection: close
Content-Type: text/html

So, there's nothing that obviously indicates that it was PHP that generated the headers in the second case, but that extra

Connection: close

header indicates there's something else going on. Very sophisticated attackers have built up default header profiles for as many web servers and dynamic runtimes as they can that looks at the exact content and order of the headers to determine what server and technology stack you may be running. A sophisticated attacker will know (or have a tool which indicates) that PHP always sends a Connection: close header, which may reveal your base technology.

I use the command line program curl to check headers.

curl -I 'http://example.com/asfasdfsd'

YOu can find more information on the OWASP wiki.

Similarly, make sure the raw text that your PHP page sends back matches what your apache server send back down to the byte level. A smart attacker would look for differences in the formatting of the output to determine if your page was a "natural" 404 or not.

The only way to tell is if the page generated by PHP is different than that of the one generated by the webserver. Otherwise, there is no difference.

You should also set the expose_php value in your PHP.ini to off so that PHP doesn't insert a header saying "generated by..." among other things. See http://blog.arvixe.com/expose-php-servertokens-apache/

I would suggest you place the file that should not be available directly outside of your DOCUMENT_ROOT if that is possible.

This doesn't answer the question, but here's a related tip: files that should never be accessed by a user directly should be placed outside the web server's document root directory.

As long as the HTTP return status code is 404, then it is by definition, a real 404, regardless of what other content is returned.

But I think you may be asking the wrong question.

Internally included files should be protected by, for example, putting them into their own directory, and using a .htaccess or other webserver directive to deny all access to that directory. Then you don't have to worry about "protecting" each and every internal file, and you don't have to worry about a programming error accidentally letting someone in.