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.

Securing Your Web Server and PHP

php.ini

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.

Options that we will configure are (see Chapter 3, "Code Organization and Reuse," and Chapter 7, "Interacting with the Server: Forms" for more detail):

register_globalsOff (Chapter 7) We will make sure this is turned off since it makes code difficult to read and is a security risk.
register_long_arraysOff (Chapter 7) Since we are going to use the latest and most proper syntax for the superglobal arrays (for instance, $_POST), we will not use the long array syntax (for instance, $HTTP_POST_VARS).
auto_append_file[empty] (Chapter 3) We will always explicitly include content we wish to add to our source files.
auto_prepend_file[empty] (Chapter 3) We will always explicitly include content we wish to add to our source files.

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:

Make sure that httpd runs as a user without super user privileges (such as nobody or httpd on Unix). This is controlled by the User and Group settings in httpd.conf.
Make sure that the file permissions on the Apache installation directory are set correctly. On Unix, this involves making sure that all of the directories except for the document root (which defaults to using htdocs/) are owned by root and have permissions of 755.
Make sure the server is set up to handle the correct number of connections. For users of the 1.3.x versions of httpd, set the value of MaxClients to a reasonable number of clients that can be processed at one time. (The default value of 150 is good, but you may increase it if you expect a higher load.) For Apache 2.0.x versions, which has multi-threading, check the value of ThreadsPerChild. (The default is 50.)
Hide files by including appropriate directives in httpd.conf. For example, to keep .inc files from being seen, you could add
```
<Files ~ "\.inc$">
  Order allow, deny
  Deny from all
</Files>
```

As mentioned previously, we want to move these files out of the document root for the specified web site.

IIS

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:

Avoid having web sites reside on the same drive as the operating system.
Spend time using the NTFS file system to remove write permissions from appropriate locations.
Delete all of the files that are installed by IIS into the document root by default; chances are you will not use a majority of these files. Large amounts of content are installed in the \inetpub directory, which you will not need if you do not use the online configuration tools (which you should notuse the iisadmin utility).
There are large numbers of automated programs that look for scripts and programs in obvious subdirectories of our document root, such as Scripts/, cgi-bin/, bin/, and so on. Avoid using common names like these to add an extra degree of difficulty for them.

Read the documentation for IIS to learn more about recommended security procedures.

Virtual Servers

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.

Securing Your Web Server and PHP

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:

safe_mode You must set this to On to use safe mode.
safe_mode_include_dir This is a list of paths (separated by a colon (:) on Unix and a semicolon (;) on Windows) for which user ID checks are disabled when scripts attempt to access files. The default of an empty string ('') means to check all files.
safe_mode_allowed_env_vars This is a comma-separated list of prefixes. The user may only call putenv to set the value of an operating system environment variable if it begins with one of the prefixes in this list.
safe_mode_protected_env_vars This is a comma-separated list of environment variables that the user cannot change through putenv.
disable_functions This is a comma-separated list of functions the user cannot call from within the script. For example, we might choose to disable all of the functions through which the user can browse directories.
disable_classes This is a comma-separated list of classes that cannot be instantiated or used by the user in script.

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:

1.	Look through the support listings before selecting a service. Better services will have complete online documentation (we even found a few with excellent dynamic tutorials) that show you how your private space is configured. This can give you a feel for what restrictions and support you will have.
2.	Look for hosting services that give you entire directory trees and not just a document root. While some will state that the root directory of your private space is the document root, others will give you a complete directory hierarchy, where public_html/ is the place your content and executable PHP scripts will be stored. On these, you can create an includes/ directory, which will help you ensure that people cannot see the contents of your .inc files.
3.	Find out what values the services have used in php.ini. While many will not print these on a web page or e-mail you the file, you can ask their support personnel questions about whether safe mode is turned on and which functions and classes are disabled. You can also use the `ini_get` function to see setting values. Sites not using safe mode or without functions disabled will worry us more than those with reasonable-sounding configuration.
4.	Look at what versions of software the services are running. Are they the most recent ones? If you cannot see the output of something, use a service, such as Netcraft (http://www.netcraft.com) to tell you which software a particular site is running. Make sure that the service is running PHP5!
5.	As we mentioned in Chapter 3, there are still options available if you are forced to use a hosting service that will not let you safely use .inc files: We can give our files a .php extension and add some code at the top to ensure that they are only called from other .php files.
6.	Look for services that offer trial periods, money-back guarantees, or other ways of seeing first-hand how your web applications will run before committing to using them.