Includes & Security

[Nutter]

I'm working on a site where every page is served as index.php?yada=yada&somethingelse=whatever. I know this is bad for SE, but it'll be a private site so that doesn't matter. I'm doing it for ease of changing. Based on the variables passed, the page includes other files to build what it needs to.

A few questions:
1 - Would it be better (more secure, harder to hack, that sort of thing) to have the included pages outside of the web path on my server. Ex: instead of include("includes/file.php") use include("/home/username/someotherdirectory/file.php"). I'm thinking this would keep "casual users" from just browsing to the file. I've already got code to redirect if any of the includes is opened directly, but figured this could add a little something else. I've done this on my development server and it seems to work, but is there anything I need to watch out for?
2 - Is it wise to keep the .php extension on the include files? I have been so that the file is parsed just in case someone tries to open it directly.

Thanks,
- Ryan

[mincklerstraat]

Hi Ryan:

1) Yes, better to keep includes out of webroot, but for a small personal site maybe not such a big deal, as long as they don't contain real key info like username and password. In that case, if your host happens to run the webserver with php turned off, you'll be sorry.

You can keep users from getting any meaningful output from include files by defining a constant

define('INSIDE_SCRIPT', 1);

in all the php files which are actually meant to be requested by the browser (and not included), and then in the included files at the beginning:

if(!defined('INSIDE_SCRIPT')) die('unauthorized access');

Use defined constants instead of set variables since if your host turns on

register_globals

, there's that small chance people could set this variable through a GET request. I sometimes, before the

die()

, first send the headers that Apache sends with 404's, and also set the die string to the Apache 404 HTML output.

2) Yes, make them .php; .inc and other extensions aren't parsed by default if they're called independently, so if there's any concern at all about users surfing these files, make them .php .

[ergophobe]

You can of course name then file.inc.php which still causes them to be parsed as PHP and yet lets you have a naming scheme that helps. If you have some control over the server, you can also set it to parse *.inc (or *.anything) as PHP.

I sometimes uses prefixes instead as in

cl_ClassName1.php
cl_ClassName2.php
T_templateName1.php
T_templateName2.php

I only bother to put security-related items outside of webroot, but then I usually have things set up with mod_rewrite so that people can't just request random files anyway and pretty much can't request any file with extensions other than .pdf, .jpg etc, but only valid page URLs

Tom

[Nutter]

Ok, the mod_rewrite comment gave me another thought. Is it possible to rewrite any request that's not to index.php to be forbidden and show a custom page basically saying "Sorry..."? That way, it wouldn't matter if the include file was parsed or not.

- Ryan

[ergophobe]

If I'm trying to make a site that's friendly and solid

- I usually rewrite all requests to index.php
- I don't have file extensions in the URLs at all
- I have some mechanism for checking whether or not the request is a valid request on the site (limited to a certain dir, the url is in a DB of pages or whatever).