The Power of PHP, both Good and Evil


Good and Evil of PHP


Generally, clients and developers are using many different programming languages to facilitate the needs of their customers and their applications. These applications include shopping carts, forums, content management system, blogs, and community portals. Over time you can see trends develop and fall in what types of applications are most popular and what languages are used most to write these applications. Some languages are popular for a while by both programmers and end users and then the popularity diminishes leaving only the hardcore developers. One language, however, that still maintains its popularity from end users to developers alike is PHP.

PHP (PHP HyperText Preprocessor) was first released in 1995 however, PHP 3.0, released in 1997, is the first version of PHP which can be considered an ancestor to today’s version. PHP 3.0 offered new features such as the ability to easily connect to different database types, API’s for ease of programming and many tie-ins to other popular functions and applications known as modules or extensions. With PHP 3.0’s object oriented nature, developers were able to easily build applications for the masses. By the end of 1998 PHP was installed on over 10% of the servers on the Internet. The most common version of PHP, PHP 4.0 was released officially in 2000. This version was rewritten from the ground up, building a new and more powerful core that could handle many different functions including sessions, output buffering, and advanced security features, as well as, wider support for web servers. This improvement in the core allowed more powerful, interactive applications to be developed with the ability to port them across numerous web servers. Today PHP is used by millions of sites worldwide due to its ease of use and ability to develop powerful, feature rich applications. According to Netcraft’s April 2006 PHP usage report over 20 million domains on the web use PHP in some form. TIOBE publishes a programming community index in which languages are ranked by developer popularity. This index shows that PHP is 4th in developer popularity, up from 5th place this time last year, so PHP is clearly on the rise, and with PHP5 gaining more support both from developers and end users, it shows no signs of slowing down.

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 is seen 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 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 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 can be followed 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. (
4. Implement a firewall solution. This can be either a software firewall or a hardware firewall. For a software firewall we recommend APF. Use 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 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. Therefore its recommended 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.

0 I like it
0 I don't like it