ScannerX

For all of us here coding in PHP, I put together a couple of configuration tips to provide an extra layer of security. Now while all of your own applications are of course bug free and will never get exploited, you just may have to use some third party code once in a while.

php.ini choices:
The following options should be no-brainers and are the default choices for current php installs:

magic_quotes_gpc = Onregister_globals = OffThe first option will automagically escape all quotes, taking essentially care of 90% of your SQL injection worries. The second part will prevent creative users from adding their own variables without you explicitly requesting them. You probably want to get rid of any php application that breaks after you turn off register_globals.

For some extra credit, you can play with 'safe_mode'. But read the instructions carefully. safe_mode is something you best enable before starting to code, as it can be tricky to enable it for an existing application.

/tmp partition:
Most php exploits need a bit of space to pull down additional code. Now we don't allow our web server to write files just anywhere. But if you are an exploit, you always got /tmp to use as your "scrap space". Probably the most effective defense against php exploits is to make /tmp its own partition and make it non executable. Don't forget to make /usr/tmp and /var/tmp a symlink to /tmp. Any other directory that has to be writable by Apache should be placed on this partition. You don't have to repartition your system. Just use a loopback file.

Honeytokens:
The two tips above should protect you from most of the automated codes thats running around the net these days with not too much effort on your side. After all, you need to get back to coding quickly. So how do you keep the more pesky little kids aways from exploring the underbelly of your applications? Now this is where a little bit of IDS and automated response can go a long way. First of all, lets talk dirty for a bit: robots.txt. As the name implies, robots.txt is for 'bots. But then again, some web developers associate magic powers with it and expect it to cloak all files listed in it from all bad influences. Now yes, this may be true. But did you use the key stroke associated with "magic spell" as you edited the file in vi? If not: your files are still all visible and robots.txt can provide a roadmap to an attacker. Consider this robots.txt file pulled from some random website:

User-agent: *Disallow: /adminpage.phpNow where would you go today attacking this website?

Simple lesson: Add a good looking file like this to your robots.txt file, with a little twist: "adminpage.php" should not unlock all your secrets. Instead, have it send you a quick e-mail and maybe have the IP added to a shun-list if this page is hit.

__________________