Hardening PHP

[Sudhakar]

Attempting To Secure PHP

This is a serious task. The goal / trick is to have PHP as secure as possible without restricting functionality beyond usability. What that means will depend much on your needs. Below is a list of some things to be aware of and to serve as a starting point for the responsible system administrator.

It is always good practice to test any new build to be sure your unique requirements are still functioning properly under a given set of build parameters.
Understand What You Are Building

When getting ready to build PHP do not blindly check and uncheck options without understanding the implications of doing so. Understand what functionality this will cause and what implications that has for the way you are running PHP. You can be sure that hackers will know how to use various PHP flaws and how to check for them so you should take the time to read the documentation and do some research.

For example, many experts recommend that "register globals" and "magic quotes" should be avoided. If scripts require them, you need to consider finding new scripts. If you do not understand why that is the case take some time to research them, you will find it very enlightening.
Master Your php.ini

One excellent way to start hardening PHP is by using your php.ini file wisely. Do a web search for "custom php.ini" and you will find many excellent articles on tips and tricks, just be sure you understand how different changes will impact users' scripts. (For example, disabling the mail() function will stop many spammers from exploiting popular scripts; however, in that scenario no scripts using this function would be able to send mail. Truly, PHP security is a balancing act.)
Run As The User Instead of "nobody"

PHP runs as part of the web server so that, among other things, certain tasks can be done once and held in memory instead of repeating them each request (IE so its not as slow as it is natively). This means that it runs as the web server's user "nobody". Since that is the case PHP and directory permissions generally need to be very loose so PHP can manipulate things. This can make it so that any user can use a PHP script to read and write other users' data. At times, a flaw in PHP can even allow a PHP script to gain root access or take over data in requests on other users PHP scripts.

You can run PHP as the user (like CGI scripts do with Apache's suexec) with EasyApache's "PHP As User" option. This will enable suPHP. This allows much better permissions. That means that vulnerable scripts are limited to the user in question and are less likely to affect other users. It also changes how PHP interacts with Apache; for example, directives like php_value are not valid for mod_suphp. Other options exist to run PHP as the user, see "Configuration of How Apache Serves PHP Requests" for more info.
Use Hardening Tools Like phpsuhosin

The suhosin extension "was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core". Is it right for you or is it too restrictive? How can you find out? What compatibility problems might you see? To answer those questions and more see the FAQ and other resources at the suhosin website.

That community would be an excellent starting point to start learning about flaws in PHP as well as other extensions, configurations, and techniques you can use to protect your server and your users.

Since many popular scripts are not compatible with suhosin's restrictions, (depending partially on how you configure it of course) it is highly recommended to test suhosin support before implementing it on a production server.
Do Not Allow Insecure Scripts

This might seem obvious but it requires diligence. It is a very nebulous concept and can range from settings policies to looking for and removing known problem scripts perhaps going as far as recommending non-PHP alternatives.