*.inc files = safe???

kikidonc

Hi,

I wondered if it was possible (and how, by the way) to avoid people to access .inc files.
I'm new at php and web in general, but when I open my .inc pages in my browser, they appear like a .doc or .txt file. Everybody can then read all the code that is inside!?!?!

If anybody knew how to avoid that...
Thanks a lot,
Fred.

lawnmowerman

If you are using Apache, you should have the following items in your configuration:

<FilesMatch "^.(ht|pa)">
Order allow,deny
Deny from all
</FilesMatch>

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

This will prevent browsers from being able to view .ht files (.htaccess, .htpasswd, etc) as well as .inc files. This will not effect the way PHP or Apache function otherwise.

-Rich

[deleted]

Another schweet way of 'securing' your .inc files is by simply naming them .php, the way they should be named in the first place.

matdoc

But you can also have it both. As vincent noted, the "inc" doesnt have a real meaning - it's just for you to distinguish between "normal" and "included" php-files.
For a secure way of achiving the same thing, just name your "included" php-files .inc.php (or .whatever.php) - this way they are parsed by the server and not just sent to the browser and the user will not see their content, if he happens to request one of these files.

Anon

Or just put the files below the web root for your webserver...

Anon

i have recently learned that the "preferred" method is to put included files in an "/include" directory which is adjacent to or above your www (or public-html) directory. this neccessitates the proper set up of the apache server however to locate and include these files (and I don't have the slightest clue how to do that).

in lieu of that, though, the *.inc.php method works very well.

lawnmowerman

Actually, it is more secure to name then *.inc and deny access to them from a browser.

Think about it this way: What happens if, for whatever reason, php is disabled? This will allow any browser to view the *.php files as plain text. You don't want that!!
If you deny access to them completely, it doesn't matter if php is running or not, the browser will still not be able to view the files.

-Rich

lawnmowerman

Unless you're running a public web server and don't allow users access outside of their web directories. 🙂

-Rich

lawnmowerman

Again, the *.inc.php method works well as long as the PHP module is running.

Placing the files inside an /include directory would also require the same type of apache configuration (FilesMatch directive) as denying access to *.inc files.

-Rich

jrmckee

If you place the /include directory outside of the DocumentRoot, the web server will not be able to read them, but PHP will be able to include them (as long as you have this option set in the php.ini file).

No Apache configuration necessary.
Jon

jrmckee

That is true, but then they probably wouldn't be able to edit the Apache configuration files either! 🙂

Jon

lucianoes

I don't understand. I keep all my includes in two directories, which contain nothing but includes. In order to view these includes, one would have to know the name and path of these files beforehand, and those are not shown to the UA in parsed documents. How can they not be safe then?

Luciano ES

[deleted]

And then if you accedently forget to disable the *.inc files, you still get to see them.

Just move the inc files to a place where apache cannot reach them, outside the documentroot.

[deleted]

Not knowing which file to look for has not stopped a single hacker so far 🙂

The question is not "can they find the file" but "can they read the file"

If they can find the file, they will find the file, it's just a matter of time.

But if they cannot read the file it's useless to them.

kikidonc

Allright guys,
I'm happy I wasn't they only one in need to discuss about that 😉

I really wanna thank each of you for your numerous replies.

I still have a question however (to Rich Alloway):
You told us about the case if php were (accidentaly or not) disable. Do we have to configure a FilesMatch for .php files as well in apache config files?
I never looked at config files until now and don't really know what is waiting for me inside :-)
Fred.

lawnmowerman

True...this will work if you don't have any users on your system attempting to use PHP and include files.

Otherwise, you will need some way to allow users to house files where the web pages are located that only they, and root, have access to.

-Rich

lawnmowerman

Why would the user need to edit the apache configuration?

Simply inform the user that .inc files are not viewable by a client's browser and are therefore a relatively safe location for usernames and passwords for db connectivity and the like.

-Rich

lawnmowerman

Hi Fred.

If you uses a FilesMatch directive to prevent the viewing of .php/.php3/.php4/etc files, then noone will be able to view your pages! 🙂

The way that we handle PHP with our hundred-thousand-or-so customers is that you are not permitted to run PHP unless we activate it for your account. Once activated, you are not permitted to place any kind of username or password within a document that is returned to the browser, parsed or not. (.shtml, .phpx, .asp, etc)
That type of data must be in a .inc file which we explicitly deny access to.
Any kind of AuthConfig configuration the user wishes to use must be in .htaccess (the default) and the password file must be .htpasswd. Since .ht files are not permitted to be viewed by any browsers, all is well.

If you have any other questions, please let me know! 🙂

-Rich

Anon

Sure, if you lock down .inc files for everyone by default, they don't need to edit it.

Jon

kikidonc

Seems to be clear!

Thank you very much once more. I'm not sure at all I'll be able one day to help you back, buf if I could... there won't be any problem at all;-)

Best Regards,
Fred.