For all of us here coding in PHP (Motto: Input validation is for people who can'tdo forensics), 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 = On
register_globals = Off

The 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. Extra super secret tip: 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. (and while you are at it, read Swa's tip about mount options). 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.php

Now 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. (Extra credit: Find out how to get yourself locked out of isc.sans.org for the next week... so no playing in the dirt while pretending to wear a white hat).

More Extra Credit:

We all love extra credit. So here a couple more pointers:

• chrooting apache/php. Not for everyone, but a very nice extra layer. Quick tip: If you still want to send email from php, look for a program called mini_sendmail.
• mod_security. very nice IDS/IPS style extension for Apache.
• swatch to monitor your log files.
• disable extensions you don't need.

And now its time for our commercial break. If you want to know more about securing MySQL, Apache and PHP, see me in Vegas in October.

Reader additions:

Richard recommends "mod_evasive" as another Apache module to consider:

"In addition to mod_security (which I think is tricky to configure well) I'd recommend mod_evasive. This tool which used to be called mod_dosevasive blocks any IP that makes too many identical requests. For pages that are CPU intensive (which PHP often is) blocking these requests can be a big win.
http://www.zdziarski.com/projects/mod_evasive/"

Sounds like a nice idea.

Daniel writes:

"Some other hints:
https://compukid.no-ip.org/dev/papers/securing-httpd/
...
Also one of the moist exploited PHP functions which should be disable by default: allow_url_fopen."

In order to disable "allow_url_fopen", check for this line in php.ini:

Of cource, there may be applications that require this feature.

----
Johannes Ullrich.