.inc security

willsteele

I'm trying to start learning PHP security and recently read this:

Don't store includes under document root.
The only resources you should store under document root are
those that must be accessible via URL.
Making anything else available to the public is an unnecessary
risk.
If you must:
<Files ~ ".inc$">
Order allow,deny
Deny from all
</Files>

If I can't install .inc files under my root, why would a related directory be any more secure? Couldn't the user, if they knew enough to search the .inc path to begin with, follow the second .inc path? Sorry if this is obvious and I'm missing the obvious.

bradgrafelman

I believe the whole point is to stop access to these files via the webserver, i.e. preventing users from going to http://yoursite.com/includes/whatever.inc and so on.

Either method would stop this. If a malicious person gains actual shell access to your server... well that's a whole 'nother story.

msound

it's a lot safer to name your include files .php. by default web browsers will display .inc and .class files as plain text, so if someone does stumble upen them they'll be able to see your code. by naming them .php even if a user finds your include file they won't be able to see any of its contents. when you think about it would you name an important php file something.txt?

stick with the .php extension, if you want to id your includes then put them in an inc sub directory or use an inc prefix: inc_somefile.php.

kakki

or you secure your incfiles with

if ( ! defined( 'noHacking' ) )
{
die( 'wrong including' );
}

and your index.php with

define ( 'noHacking', true );

bradgrafelman

The whole point of this persons post was to either:

a.) Put the .inc files outside of the web root, or
b.) Secure the web directory so that no one is allowed to access it

If the directory is secured as he showed in his post, I don't know that all of this is really necessary. I suppose some freak accident by the host might disable .htaccess files and a malicious person might get lucky, but how often does that happen??

Personally, I would definitely go for the directory above your web root. If you can not do that, perhaps mix and match the above suggestions: secure the directory with a .htaccess file, and use something like .inc.php for a file extension (ex. config.inc.php) so that you know the files are special include files (.inc) but they can be secured using PHP, such as checking for a defined constant (kakki gave a coding example of this).

msound

Actually the topic of this post was .inc file security. The OP's first post outlined the security methods he's already come to understand but it also says that he's new to PHP security. The only time you can ever be too careful is when your security gets in the way of functionality. Kakki and I both gave additional security suggestions that shouldn't limit the functionality of the OP's applications in any way.

One could go a step further and say that the include files should be stored in a directory that isn't accessible by remote users, most notably FTP. A lot of web hosts give FTP users access to the ServerPath and not just the DocumentRoot. This makes sense because it allows users to access the cgi-bin, but it also creates an additional way for bad buys to gain access to all of your server side include informaiton, which probably includes your database connection info.

MarkR

What I do is:

Call my include files .php
Ensure that if any of them was executed directly, it would do nothing that might have a detrimental effect - this is ensured by only ever defining things (define(), functions, classes, globals), not actualyl doing anything. It should be safe anyway.
I also put my includes in an include/ directory which contains .htaccess saying simply "Deny from all".

Any of these things alone is sufficient to stop the end user from seeing the contents of my files, but all three makes it very unlikely. It would require at least two independent configuration errors for someone to see the contents of my includes. Both of them would probably individually break the site, so would be unlikely to go unnoticed.

Mark