Securing Your Web Server and PHP
In addition to code security, the installation and configuration of our web server with PHP is a large concern. Much of the software that we install on our computers and servers comes with configuration files and default feature sets designed to show off the power of the software, and assumes that we will work on disabling those portions that are not needed and are less secure. Tragically, many people do not think to do this or do not take the time to do it properly.
As part of our approach to dealing with security "holistically," we want to be sure that our web servers and PHP are properly configured. While we cannot give a full presentation of how to secure each web server or extension you might use, we can at least provide some key points to investigate and point you in the correct direction for more advice and suggestions.
Keep the Software Up-to-Date
One of the easiest ways to help the security of your system is to ensure that you are always running the latest and most secure version of your software. For PHP, the Apache HTTP Server, and Microsoft's Internet Information Server (IIS), this means going to the appropriate web site (www.php.net, httpd.apache.org, or www.microsoft.com/iis) on a semi-regular basis and looking for security advisories and browsing through the list of new features to see if any are security-related bug fixes.
Setting Up the New Version
Configuration and installation of some software programs can be time-consuming and require a number of steps. Especially on the Unix versions (where you install from sources), there can be a number of pieces of software you have to install first, in addition to a number of command-line switches required to get the right modules and extensions enabled.
Write this down! Make yourself an installation "script" to follow whenever you install a newer version of the software. That way, you can be sure you do not forget something important. There are so many steps that it is highly unlikely our brains will remember every detail each time we run through an installation.
Deploying the New Version
Installations should never be done directly on the production server for the first time. You should always have a practice or test server where you can install the software and web application and make sure everything still works. For a language engine like PHP, where some of the default settings change between versions, you will want to run through a series of test suites and practice runs before you can be sure that the new version of the software does not adversely affect your application.
Note that you do not need to go out and spend thousands of dollars on a new machine to practice setup and configuration. Many programs that allow you to run an operating system, such as VMware, Inc.'s VMware or Microsoft's VirtualPC software, let you do this within the current operating system you are running.
Once you have verified that the new version of the software works well with your web application, you can then deploy it to production servers. You should be sure that the process is either automated or scripted on paper (or disk) so that you can follow a sequence of steps to replicate the server environment. Some final testing should be done on the live server to make sure that everything has gone as expected (see Figure 17-1).
Figure 17-1. The process of upgrading server software.
If you have not spent time browsing through php.ini, now is a good time to load it into a text editor and look through its contents. Most of the entries in the files have adequate comments above them that describe what they are used for. They are also organized by feature area/extension nameall mbstring configuration options have names starting with mbstring, while those pertaining to the Microsoft SQL Server are prefixed with mssql.
There are a large number of configuration options for modules that we do not use, and if those modules are disabled, we do not have to worry about the optionsthey will be ignored. However, for the modules we do use, it is important to look through the documentation in the PHP Online manual (www.php.net/manual) to see the values and options of that extension.
It is highly recommended that we either make regular backups of our php.ini file or write down the changes we have made so that we can be sure that the correct settings are still there when we install new versions.
The only trick to these settings is if you choose to use legacy software written in PHP, it may require that register_globals or register_long_arrays be turned on. In this case, you must decide whether using the software is worth the security risk. You can mitigate this risk by checking frequently for security patches and other updates.
Web Server Configuration
Once we are comfortable with the way we have configured the PHP language engine, we will look at the web server. Each server tends to have its own security configuration process, and we will list the ones for the most popular two servers here.
Apache HTTP Server
The httpd server comes with a reasonably secure default installation, but there are a few things we will want to double check before running it in a production environment. The configuration options go into a file called httpd.conf, which is in the /conf subdirectory of the base installation of httpd (for instance, /usr/local/apache/conf or c:\Apache\conf). You should make sure that you have read the appropriate security sections in the online documentation for the server (httpd.apache.org/docs-project).
In addition, you should do the following:
As mentioned previously, we want to move these files out of the document root for the specified web site.
Configuring IIS does not revolve around settings files as much as the Apache HTTP Server, but there are still a number of things we should do to secure our IIS installation:
Many web servers available today support the ability to host multiple web sites or web applications from the same IP address via virtual servers. Since HTTP/1.1 includes the name of the server for which a request is being made, the web server can manage multiple sites at the same time while only using one IP address for the computer (see Figure 17-2).
Figure 17-2. Virtual web servers on one physical server.
The huge downside to this is that all of these virtual web sites run with the same user details and permissions as the web server; this means that any web site can access the details of the other web site, load in its files, and write to any of the files. Attempting to "hide" files by putting them in nonstandard locations can help to a minor degree, but PHP includes directory listing functions, such as scandir, which let you list all the files in a specified directory.
The ability to separate virtual servers from each other and provide an optimal level of security is something that would best be done by the web server. Alas, it is not currently implemented by default in any of the major web servers available. While some have experimental extensions to try to make this work (the suEXEC extension for Apache HTTP Server comes close), a truly robust solution does not exist.
Therefore, for maximum web application security, using virtual servers is not recommended.
PHP has something known as safe mode by which it attempts to provide virtual servers a degree of protection. While it is not a perfect solution, it might provide enough security for simpler web applications.
Safe mode works by comparing the user ID of any file you try to access to the currently executing script. If they are the same, you can access that file. If they are different, but your script's user ID is the same as that of the directory in which the file resides, you can access that file. Otherwise, access to the file is denied.
Using Safe Mode
To use safe mode, you must first edit php.ini and change some of the settings:
You should spend some time testing your installation if you plan on using virtual servers to make sure that nobody can access files in your web application, especially in environments where you are not sure who the other site operators are (such as a public ISP who hosts PHP servers).
Commercially Hosted Web Applications
However, there is one group of users for whom the problem of security on virtual servers is a bit more problematicusers running their web applications on a commercial PHP/MySQL hosting service. On these servers, you will not have access to php.ini and will not be able to set all the options you would like. In extreme cases, some services will not even allow you to create directories outside of your document root directory, depriving you of a safe place to put your include files. Fortunately, most of these companies wish to remain in business, and having an insecure design is not a good way to keep customers.
There are a number of things you should do as you look into a service and deploy your web applications with them: