Hiding SSI target files

Deny access to browsers but not Apache itself

[rawling]

I'm trying to use an .htaccess file to stop browsers being able to open my SSI include target files if they manage to guess the address.

All files are of the form filename.html.inc (with scope for other extensions e.g. .txt.inc etc.)

I tried adding the following to the .htaccess file, thinking that Apache would block browsers from viewing the .inc files but would still be able to use them itself to fulfil an SSI directive; this wasn't the case, and I got the standard (paraphrasing) [an error occurred while processing this directive] message.

<FilesMatch "\.inc$">
Order allow,deny
Deny from all
</FilesMatch>

Is there a way I can do what I want? Can anyone help me out?

Many thanks

[jdMorgan]

With mod_rewrite:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^.]+\.)+inc(\?[^\ ]*)?\ HTTP/
RewriteRule \.inc$ - [F]

By checking THE_REQUEST, we can be sure that only direct client requests for .inc files are denied.

An example of THE_REQUEST might be:

GET script.php?prod=widget&color=red HTTP/1.1

The pattern of the RewriteCond is a bit complex in order to avoid any possible ambiguity.

If you have no other working mod_rewrite code you will need to add either both of these lines or just the second line ahead of the code above:

Options +FollowSymLinks
RewriteEngine on

Jim

[rawling]

Thanks for the response.

I wonder, could you just briefly walk me through what this -does-? :)

[jdMorgan]

If the request from the client is for a page with a .inc file extension, return a 403-forbidden response. If a .inc file is requested as the result of an internal request, do nothing.

For more information, see the documents cited in our forum charter [webmasterworld.com] and the tutorials in the Apache forum section of the WebmasterWorld library [webmasterworld.com].

Jim

[rawling]

Aah, that makes sense, Thanks a lot :-)

[rawling]

Hmm, sorry to bump this, but is there a way to get Apache to return a 404 rather than 403 message, by replacing the [F]? The closest thing I can find in the documentation is [R=#*$!] but it says #*$! should be in 300-400 as it's really a redirect.

[jdMorgan]

Not sure why you'd want to do that, as the resource cannot both exist and not exist, and returning status that says that it doesn't exist when in fact it does can confuse clients and lead to unexpected results.

But you have two options: Return a 410-Gone response using the [G] flag on RewriteRule, or internally rewrite the unwelcome URL-request to any file-path that does not exist. Once the request is rewritten to a truly-non-existent file, the server will detect that, and return a 404-Not Found response.

410-Gone is the correct response for a resource that has been intentionally removed. It indicates that the requested URL was correct, but has been removed. On a well-run site, every URL that has ever been removed will return a 410-Gone response.

404-Not Found indicates that the server, for an unknown reason, cannot locate the requested resource. Either the requested URL was incorrect, the server has a problem (e.g. mis-configured or a bad script), or the resource was intentionally or unintentionally removed. On a well-run site, a 404-Not Found is an indication that something is seriously wrong, and that immediate attention by the Webmaster is required. (If a site is constantly generating 404 errors, then the occurrence of a 404 error becomes useless as a debugging tool, and by my definition here, the site is not "well-run." This is not to say that most sites are well-run, they aren't. But if I see a single 404 on any of my own sites, that means that I've either got an unexpected emergency on my hands, or that someone is (possibly-intentionally) requesting invalid URLs from my site -- perhaps as a security-exploit probe.)

410-Gone is to be preferred in the case where you wish to provide accurate information to the client. I'm not sure if that's the case here, though...

Jim