PHP is the most commonly used web application framework and the level of security it provides is often debated. However, what is factual is that it has no default security mechanism. Identical PHP applications are often widely deployed, so a vulnerability in a single application can result in a large number of insecure, publicly accessible servers. In fact, 30% of all vulnerabilities in the National Vulnerability Database are linked to PHP. Resulting, PHP developers not only need to have a solid understanding of how the Web and HTTP works, but they also need to understand secure coding practices specific to the nuances of PHP.
PHP is well suited for interfacing with the Operating System. Even if the functions to execute OS commands are disabled (they usually are not) there are enough PHP functions available to carry out many common system tasks such as file manipulation, database access, and network operations. The implications of this are massive – being able to execute PHP code allows the attacker to control the server and use "web shell" applications that make the ability to control compromised servers scalable. PHP "web shells" are easy to write and readily available, and PHP applications are particularly prone to vulnerabilities that allow execution of arbitrary PHP code, making PHP an ideal target for attackers. On top of this, when PHP servers are compromised, the attacker gains access to the server itself, the database hosting the application's data, and the traffic of the application’s users. Traffic can be redirected to a client-side exploit (usually targeting the Java framework browser plugin) to build a botnet out of the application's users and the server itself.
The first step to making PHP more secure is to prepare its environment: update PHP and the system, and configure the web server and php.ini file correctly. It is important to update PHP because there have been several important security-related updates in the past several years: register globals has been disabled by default and the hash-collision DoS vulnerability has been fixed. Additionally, the system as a whole needs to be continually updated. If it's a Linux system, it's important to keep everything up to date, but especially the kernel. If an attacker manages to compromise a PHP web application, they are most likely to attempt a privilege escalation exploit in the kernel. There are privilege escalation exploits for Windows as well, but they are usually limited to the Windows OS itself and can be remedied using Microsoft-supplied updates.
The Web server needs to be configured for security too. First of all, it must be executed using a limited user account. This is particularly important for Windows where the temptation to run applications as an Administrator user is greater than for Linux (although it goes without saying that running Web servers as root on Un*x systems is a known bad practice). While configuring the server, make sure that it is not vulnerable to the connection exhaustion (aka Slowloris) attack. Mitigating this attack differs from platform to platform and requires some level of reconfiguration. Additional security countermeasures include getting a valid SSL/TLS certificate, configuring TLS to use only strong cipher suites, and configuring php.ini for security (while there is a lot involved, the general mitigation principle is to disable dangerous PHP functions.)
While server issues (misconfiguration, failure to patch, etc) undoubtedly contribute to the problem, the root cause remains poor PHP development practices – and hackers feed off of them. A primary factor is that there is no clear and authoritative source on secure PHP development practices. The php.net site, as comprehensive as it is, occasionally provides insecure practices (hopefully they've getting better at catching them), and there are many other Web sites that actually show how to code in PHP the wrong way. Compounding the problem, many PHP coders don't have special security training and are prone to write vulnerable PHP code. That's one of the dominant trends of Web 2.0 from a security perspective: self-taught PHP developers writing dangerous code for a ubiquitous platform, and cybercriminals exploiting this code to build botnets which are then used for large-scale DDoS attacks, fraud and all kinds of madness.
The way to break this trend is to help PHP developers write safe code by providing them with clear guidance on how to do so. There are proven best practices for avoiding most of the PHP pitfalls that lead to the types of vulnerabilities that can be scaled for building large botnets. Below are a few resources for Secure PHP coding:
