Securing the vulnerability monster (PHP)
On any Linux distribution, simple package install commands are enough to get a LAMP stack up and running. The distribution always put default configuration files, but defaults are always insecure and overhead. Lets make it secure and fast by small tricks.
These settings will not fit everyone, but should work fine with most applications.
This option restrict script to access only certain directories and needed when security matters. Note, in development environment it must be empty, but in production environment, users should not access directories outside their own sandbox. It’s a good idea to set this from php.ini and additionally from the Virtualhost configuration:
It’s not safe and most open source systems crashes with this option turned on in php.ini. I have solid debate with retrograde system administrators, they are jibbing. So, safe_mode must be turned off:
PHP has a couple of built-in security vulnerabilities. We should disable all of it. Note the preg_replace, because with the ‘e’ modifier, user can run any code. This can be very dangerous if not properly monitored – if we allow the user to provide the variable then effectively they could execute any code they within our file. The ‘e’ modifier does try to get round this by escaping some characters (‘, “, \ and NULL), however it still leaves it open to some vulnerability.
PHP version information for the script kiddies
By default PHP will issue a header containing the fact PHP was used, and the version you are using. Essentially telling a potential attacker which exact version of PHP to look for vulnerabilities for. Prevent this by setting:
By default, PHP prints every error to the stdout, allows visitor to know which PHP file does the error and why. It’s very bad. Turn it off for production environment:
The dynamic library loading is affected only on Linux systems, because IIS can’t do that and disabled automatically. If not, with dl() call, users can load unwanted PHP libraries.
Through FOpen, you are able to access internet URL’s as if they were local files and even include remote files for execution. But what happens when the remote machine broken and throws you malicious response. Disable it and tell your development team to really never use it.
Use PHP through FastCGI. This has the added advantage of a lower overhead, as the PHP interpreter is always running and not loaded on each request, and allows you to run PHP as a different user and from that point UNIX file permissions take over access to certain files and directories.
It is also possible to install a patch to PHP called Suhosin, which includes greater security and offers more flexible configuration options. Most Linux distribution comes with a Suhoshin hardened PHP. Simply use it.