The Power of PHP, both Good and Evil

However, there is an ugly side to PHP and its rise over the years. With PHP’s immense popularity and accessibility to inexperienced website owners through pre-built scripts and do-it-yourself auto-installers, it will come as no surprise that PHP coded applications are a favorite target of hackers and script kiddies.  It does not help that PHP has regularly had numerous vulnerabilities and exploitable function throughout its life.  These vulnerabilities, due to PHP’s popularity, are magnified as the exploitation of them spread like wildfire from one server to the next by automated attacks searching for the vulnerabilities.  These vulnerabilities and the resulting attacks have long been a headache for web hosts trying to keep their servers from getting attacked or being hacked.  In addition to the vulnerabilities, PHP has functions such as fopen(), include(), and exec() which in and of themselves are great tools for building dynamic applications.  However when code is not written properly, a hole in which these functions can be exploited emerges, allowing script kiddies and what would normally be considered other low level attacks to run DOS attacks, PHP Shells, download exploits and execute other malicious code from your server that might otherwise be fairly secure.  The wonderful nature and ease of deployment with PHP that does so much good, is the same reason that it’s a common tool for evil. One with malicious intent does not need high level experience or heightened permissions in order to inflict harm upon your systems. So what can you do to protect your servers and possibly you business before it gets hit by an attack?

PHP’s default installation is pretty liberal on what it allows out of the box and could use some tweaking for security.  However PHP only really offers the “safe mode” option which essentially locks the PHP installation down and restricts users from using most functions, which is a difficult proposition for shared hosts wanting to allow their clients some flexibility and control of their code. Therefore you have to take a different approach to security. What CWIhosting.com has found is that the layered security model is much more effective compared to a “fix it all” application that you can buy, and most other methods.

The first thing we recommend is that if you are a developer or coder, make sure the code you write is secure.  If you are a messy coder who just codes without thinking about the implications of your code, there are resources out there to help you. The PHP Security Consortium (www.phpsec.org) is an international organization of PHP experts that are dedicated to researching and publishing vulnerabilities, how to avoid them and other pertinent articles. For developers, there are other resources out there for you as well that are worth looking into. One of the easiest to use is the Writing Secure PHP Cheat Sheet located at http://www.ilovejackdaniels.com/php/writing-secure-php/ and is a great desk companion for when you are writing code. It takes a down to earth look at many of the coding practices that cause PHP vulnerabilities that have given web hosts and users many headaches. As a developer, you must be mindful of what you are doing and think about the possibility that your code could at some time be compromised. Web hosts and server administrators know they can not anticipate what every client will do with PHP, and for this reason, it is only the first line of defense. However, education and regular updates on writing secure code and new vulnerabilities can go a long way.

Secondly, we recommend securing your system in a layered manner if you can, or use a web host that does. If you are unsure what your current web host does for security you can use this article as a basis of questions for them. The following are steps which CWIhosting.com has taken to increase security and stability related to PHP by significantly measurable margins, and has helped reduce PHP security related incidents.

1. If you are not already subscribed, you should subscribe to the Security Focus newsletter.  Not only do vulnerabilities for PHP get listed but other vulnerabilities pertaining to your entire server.
2. Regularly visit the PHP Security Consortium Website, it may be primarily for developers however web hosts and server administrators should be aware of many vulnerabilities so you can explain them to your customers.  Education in many cases can be the key.
3. Setup a PHP security FAQ for those customers who do their own coding and for those customers who have developers. The Open Web Application Security Project has published a top ten PHP security blunders article which is a good start for a FAQ. (http://www.sklar.com/page/article/owasp-top-ten)
4. Implement a firewall solution.  This can be either a software firewall or a hardware firewall.  For a software firewall we recommend APF. CWI Hosting uses both Cisco PIX hardware firewalls and software for added layering. This step will help out for other general security issues as well. In addition, a firewall is great for blocking sniffers when found as they tend to cause increases in load and resource consumption even if they ultimately do not find a vulnerability on your system. Closing off all unused access points and changing the way you connect to the ones you do use is always a good security idea.
5. Implement an intrusion detection package like BFD which will work with APF software firewall and will automatically block suspect IP’s.
6. Implement Mod Security for your Apache based web servers.  Mod_security is a life saver in combating vulnerabilities, especially with the many PHPBB vulnerabilities that have existed in the past.  Got Root (www.gotroot.org) has many custom rules that you can download and use to help protect the server.
7. In php.ini disable allow_url_fopen and only allow it on a per user basis so that you can control who uses this. Some shared hosting clients may take issue with this, but once the ramifications are explained, the vast majority is supportive. Ultimately, system administrators, clients and users want stability.
8. Restrict access to functions like phpinfo, dl, readfile, and exec.
9. Setup and configure Open BaseDir for your server users.
10. Ensure temporary directories such as /tmp and /var/tmp will not allow execution of scripts that could be created there due to insecure PHP code.
11. Disable register_globals in php.ini.  If a customer needs this for their scripts to function it can be enabled on a per account basis.
12. Disable access to binaries on your system. By default, PHP allows an application to access any binary on the system through the system() and exec() functions.  In many cases a web host cannot just disable access to these functions without breaking an application or two. However there are creative ways in which a system administrator can limit the binaries which PHP can see, thus reducing the number of binaries allowed to those that the system administrator wants to allow.

With the above steps you should be able to curb many of the most common and some not so common vulnerabilities that web hosts will encounter when customers use PHP scripts. At CWIhosting.com we have had these and other procedures implemented for over a year with great success, therefore CWI knows that implementing them in your environment will ease frustration and increase security.

A new battlefront is beginning to grow with the spread of PHP5 outside of the development community into the mainstream arena.  Although PHP5 is developed to take object oriented programming to the next level, allowing developers to write cleaner, friendlier and more optimized code, this does not mean that applications without holes will always be created. Just as with any new software version, there are going to be new hurdles, holes and problems to overcome.  However, you are lucky due to the fact that the php.ini for PHP5 is not greatly changed so many of these processes can be duplicated in PHP5 allowing you to start securing even the newest PHP versions to a more suitable level.

Remember security isn’t something you can just tack on; it’s a team effort involving users, developers, administrators and providers. If it is not integrated into the design of your overall processes and continually looked at, you are seriously increasing your risk of being attacked. That could mean potential disaster for you and your business.

Author:

Jason A. Taylor
Chief Technical Officer
www.CWIhosting.com

About Jason A. Taylor

Jason Taylor has extensive server administration experience including pioneering a private JVM for shared java hosting. He is the Chief Technical Officer at CWIhosting.com and one of the original founders. www.CWIhosting.com specializes in complete online business solutions for Small to Medium sized businesses sense 1997.