PHP Security Basics: Shared Hosting (Part 1)

PHP has an undeservedly poor reputation for security. While it is true that PHP doesn't force programmers to use secure practices, this is also true of most other programming languages. PHP programmers should view security as both a challenge and an opportunity. A challenge because no one except the attacker is happy when sensitive data is exposed. An opportunity because the ever shifting nature of security threats means that this is not an area that is going to be automated any time soon. Security is an area for PHP programmers to display skill and build a valuable reputation.

Server security is a prerequisite for all else, but generally a PHP programmer's responsibility in this area is going to be limited to choosing secure passwords, using ssh and sftp, and using high privilege accounts only when necessary. That said, programmers developing for mass markets would be wise to keep in mind that their application will likely reside on shared hosting at some point. The security of shared hosting can range from good to appalling, but it is never going to earn 5 stars. It is a simple fact that the number and variety of attack vectors are an order of magnitude higher on shared hosting, particularly if the server administrator doesn't take steps to harden the various default installations.

So what needs to be done to accommodate shared hosting environments? You probably aren't going to like the answer, so let me scare you a little bit first. In non-VPS shared hosting environments, you should assume that an attacker has full access to your PHP source code, including any database authentication credentials if, as is typical, you set those in a PHP file. Of course, even on dedicated servers, your PHP source code should be stored outside the directory tree that is published by the web server, but these files still need to be accessible to the PHP-enabled web server, so in a shared hosting environment, an attacker may be able co-opt the web server into exposing them. There are hosting-side measures that can be taken to mitigate such risks (chroot comes to mind), but the point is to stay out of the business of predicting or dictating user hosting environment requirements. Defense-in-depth is never a bad idea either. Even the best hosting environments can be compromised. In fact, it is the best hosting environments, along with their high value applications and databases that are most likely to be targeted by an attacker.

So what's the solution? There isn't a good solution, but the best option in a shared hosting environment is to store your source code in the database. And the database authentication credentials? Again, there isn't a good solution, but the best option is to store the credentials in environment variables that are available only to your instance of the web server. If you choose this option, you must be quite careful not to make the contents of _SERVER public, for example, via phpinfo.

Even if you're willing to trust hosting-side solutions for this particular vulnerability (i.e., source code exposure), shared hosting also makes your session data vulnerable to exposure and even modification by an attacker. We'll look at the problem and solutions next post.

Image credit: B Tal