Tightening PHP revolves largely around its configuration file, php.ini, so let's crack into that (before someone else does!)
Locating your configuration options
Even with some shared hosts there's quite a lot you can do to tighten up your PHP installation.
In cPanel, for example, you can investigate your options by choosing the main menu's php.ini QuickConfig icon and selecting Enable QuickConfig.
For unmanaged types, open your php.ini file with a terminal. The path may vary but can be located with sudo find / -name php.ini -print or, if there's more than one file, add a temporary .php page containing the code <?php phpinfo();?>, browse there and look for this:
That done, delete the file before someone else looks too. And open the .ini:
Making .ini a meany
Here are the key security variables along with the defaults for PHP 5.3.2, at least, but these defaults change quite a lot so it's important to check yours, ensuring wpCop's recommended values are set.
|allow_url_fopen = On||Off||Allows remote file includes but assists RFI attacks|
|allow_url_ include = Off||Off||Ditto|
|display_errors = Off||Off||Development tool, creates info leak for live sites|
|enable_dl = Off||Off||Loads extensions, can negate open_basedir, below|
|;error_log = /var/log/php_errors.log||remove ;||Enables the log, the better live site alternative to showing in-browser errors|
|expose_php = On||Off||More unnecessary info leak|
|magic_quotes_gpc = Off||Off||A ‘security' feature that makes things worse.|
|;open_basedir =||open_basedir = /path/to/www||Isolates PHP scripts (see below)|
|register_globals = Off||Off||It's deprecated and dangerous|
|safe_mode = Off||Off||Disables functions but disable_functions (see below) is better|
Disable unnecessary PHP functions
Touched on above, disable_functions allows us to turn off things we don't need and, bearing in mind that active functions add security risks, we like that.
Look for disable_functions = and add these known trouble spots, none of which assist the average WordPress site:
This is an oh-so-tight – yet generic – configuration that should play nice not only with WordPress but also with any other PHP application being served from your host. Please drop by the forum to let me know if you experience any differently. (Thank you.)
How to set up PHP's open_basedir function
open_basedir, like many directives, is not infallible but, by jailing PHP scripts to a restricted area, it's a great help and is not dissimilar to the chroot jails preventing the users on a shared hosting server from accessing other user's files.
By default it is not active and, generally, is activated in php.ini to protect the server's total web space area.
… This is good news but consider the added security of jailing PHP scripts not merely to your server's overall web space but rather to the folders for each and every website on the server.
To do this, ignoring the default php.ini variable, we instead configure the open_basedir function in each of our site-specific configurations, for instance in each of the virtual host files (our site configuration files). Here's an example rule in a site configuration's location box:
… The path depends on your particular setup, of course. Having set the rule, cruise your site and, assuming you've enabled it, check the php_errors.log. Any open_basedir errors will tell you what paths are missing and you can add them to the value separated by colons, so that's like this:
Here's some reference for the official scoop on all PHP directives:
Patching PHP with Suhosin
Originally called the Hardening-Patch, Suhosin is a Korean word meaning “guardian angel” and, while this defense isn't that fabulous, it's nonetheless a must-have PHP accessory.
So what does it do? It helps to shield servers from fallible code. The complete spec, which runs as long as your arm, can be found precisely here.
The chances are you already have Suhosin. The simplest check requires the phpinfo function to be re-enabled (sorry!).
To do that, create somepage.php, insert <?php phpinfo();?> within, browse to the page and search for Suhosin. If you can't find it, install it:
With the mainstay defenses added to PHP we'll take a look now at an even stronger, albeit more involved, alternative to the open_basedir directive, SuPHP (and its cousins), in Setup SuPHP to Isolate Risk.