MySQL & PHP From Scratch

Security Issues

Problems arise when users try to make your Web server give them documents or files you don't want them to have. PHP is written with this in view. Let's look at some possible attacks, and how PHP would handle them. Because our project uses PHP, the information here describes how the PHP-based IMP system will respond to some types of attacks.

NOTE

To add value to your IMP system, you might want to provide a welcome page to your system that has a link to your IMP login screen from one or more places. Your welcome screen could sign up a user and add that user to your system, making IMP immediately available.

To do this, you will need to run another Web application. If you use any helper CGI programs within your IMP system to run that application, you need to know about the issues covered in this section.

I will cover the precautions PHP takes when it is being used as a CGI program. Other CGI programs should also take these precautions . You need to check those programs for compliance to these security issues.

Users that have permission to execute programs in the Web server's cgi-bin directory can sometimes fool a cgi script to send them a file. One attempt could be a URL similar to the following:

http://www.servername.com/cgi-bin/php?/etc/passwd

If this line succeeds, the CGI script tries to interpret /etc/passwd as a script. In many cases, the CGI script will give you the contents of the file along with error messages. PHP is written to prevent this. PHP will not

interpret the command-line argument, which is /etc/passwd, and so won't try to open that file.

NOTE

Nevertheless, PHP scripts can be vulnerable if incorrectly written. The version of IMP prior to 2.0.11 had a bug in it where it would display any readable file in the system. The 2.0.11 release fixes this problem.

Another attack would be to try to get access to hidden parts of your file server. A username and password normally protect those parts . (The Apache documentation covers these types of Web pages.) This type of URL could look something like this:

http://www.servername.com/cgi-bin/php/mysecret/document.html

To avoid this, PHP allows you to set a compile-time option --enable-force-cgi-redirect. This option tells PHP that you can't trust your Web server. When you use the Apache Web server, the environment variable REDIRECT_STATUS is set. This environment variable is unique to Apache, and tells PHP whether it is safe to use the redirect information on the command line. This is not a concern for your project, unless you decide to run PHP as a CGI program. I guide you through installing PHP to run as a module, so this will not be an issue.

When PHP is included as a module in the Apache Web server, it is run with the privileges of the user that Apache runs as. The Apache Web server typically runs as the user nobody. This user cannot log on to the system. This user is in it's own group . With this precaution, it is easy to protect a document from prying eyes by making it impossible for the user nobody to read it.

TIP

If you have sensitive information on your system, and are paranoid about possible access from other users, you can protect a document by making it unreadable by anyone but the owner of the file. The command line for doing this under Linux is

chmod o.rw, g-rw, u+rw filename

Running PHP with Minimal Risk

The best way to run PHP is as a module under Apache. When running as a module, most of your possible security issues fall under the umbrella of the Web server. Apache has proven itself to be very secure.

If you really must run PHP as a CGI script, you should use the --enable-force-cgi-redirect compile option. This will provide a minimum level of security.

Apache Configuration Issues

The PHP rpm that Red Hat included on its installation CD with version 6.1 is severely broken. It simply will not let Apache run when it includes PHP as a module. I browsed the Red Hat site at http://www.redhat.com/errata, and attempted to find a note or correction about this. No such information was forthcoming. To test the PHP and IMP configuration changes just made, you need to build PHP with the correct options and install your build. These steps will be covered in Chapter 5.

In some cases you might try to restart your server and get the following message:

[root@wmaxlaptop php-3.0.16]# /etc/rc.d/init.d/httpd restart

Output

Shutting down http: [FAILED] Starting httpd: httpd: cannot determine local host name. Use the ServerName directive to set it manually. [FAILED]

This happened to me because I am not on a local network with a DNS server. The best way to handle this is to make sure that the hostname the Linux machine is currently using is in the /etc/ hosts file along with the correct ip address. Then edit the /etc/httpd/conf/httpd.conf file, and change the ServerName directive to the name you have chosen for your machine, or its IP address. Be sure to remove the # in front of the ServerName directive, as that turns the line into a comment line:

# # ServerName: allows you to set a host name which is sent back to clients for # your server if it's different than the one the program would get (i.e., use # "www" instead of the host's real name). # # Note: You cannot just invent host names and hope they work. The name you # define here must be a valid DNS name for your host. If you don't understand # this, ask your network administrator. # If your host doesn't have a registered DNS name, enter its IP address here. # You will have to access it by its address (e.g., http://123.45.67.89/) # anyway, and this will make redirections work in a sensible way. # ServerName lin

Now you can restart the Web server. Note the number of httpd processes that are running:

[root@wmaxlaptop conf]# /etc/rc.d/init.d/httpd restart

Output

Shutting down http: [FAILED] Starting httpd: [ OK ] [root@wmaxlaptop conf]# ps ax grep httpd 1414 ? S 0:00 httpd 1417 ? S 0:00 httpd 1418 ? S 0:00 httpd 1419 ? S 0:00 httpd 1420 ? S 0:00 httpd 1421 ? S 0:00 httpd 1422 ? S 0:00 httpd 1423 ? S 0:00 httpd 1424 ? S 0:00 httpd