Ten Security Checks for PHP, Part 2

In the previous article, we explored five security checks for PHP code; in this article we explore five more.

Use the .php extension for all script files

Many PHP programmers use .inc or .class extensions for library and configuration files that are accessed by the include function. If a malicious user fetches the URL for the .inc or .class file in their browser they will be able to see the contents of these files, including any PHP code. This may reveal intellectual property, passwords or weaknesses in your code.

What to Look For

Examine the file names of all script files.

Possible Fixes or Improvements

• Use the .php extension for all script files
• Place library and configuration files outside the web server's document root directory

Place sensitive content outside the document root directory

Many PHP systems are designed to restrict access to documents or images through user authentication and access control lists. However, these documents are frequently stored as files in a subdirectory of the directory containing the PHP scripts. This makes these files available directly by using the appropriate URL in your browser.

Don't put secured content under the application root; for example, don't put an image which is meant to be password protected under the application root.

What to Look For

Examine the placement of directories used to store files containing privileged content.

Possible Fixes or Improvements

• Store content as files in a directory outside the web server's document root directory.
• Store content in a database.
• Use web server features such as Apache's .htaccess files to prevent direct access to content directories.

Beware of Shared Servers

Many PHP sites take advantage of cheap third-party hosting. Such hosting usually involves sharing a server with other users. Another user may be able to use a PHP script or shell access to modify, access, or delete your files or to determine database passwords. Another potential attack is the ability to create a session file (by default stored in /tmp) that would allow the malicious user to bypass your authentication.

What to Look For

If you are using a shared server look at the configuration of the server using the phpinfo function. Also examine the permissions on sensitive files.

Possible Fixes or Improvements

• Use a dedicated server instead. Hosting companies usually have dedicated servers available at higher prices, but the security and performance gains may justify the expense.
• Ensure the hosting company turns on the safe_mode configuration setting. (You can check by writing a script that runs the phpinfo function.) However, the safe_mode function can also prevent the execution of other programs, limiting the functionality of your site.
• Set file permissions such that the web server can only read files if it knows their name. (On Unix systems, give directories modes like 711.)

Avoid Loose Typing Intricacies

PHP will often convert the type of a variable from one type to another type to suit the current context in which it is being used. These problems are hard to identify, but have lead to holes in popular PHP software such as phpMyAdmin. Consider the following code:

<?php
    // A simple user list - the key of each array is the user number and
    // the value is the password
    $users[0] = ""; // Guest user
    $users[1] = "password1";
    $users[2] = "password2";
 
    // Check that the user has entered a user ID of 0, 1 or 2
    if ($user_id < 0 || $user_id > 2 || !isset($user_id)) {
        die("Invalid user ID");
    }
 
    // Check that users apart from guest have entered the correct password
    if ($user_id != 0 && $password != $users[$user_id]) {
        die("Password invalid");
    }
 
    // Print a message telling the user what type they are
    if ($user_id) {
        echo "You are an authenticated user";
    } else {
        echo "You are a guest user";
    }
?>

The code appears to have done the necessary checking to ensure that a valid user ID is provided. A list of parameters and outputs is shown below:

What to Look For

This problem can be hard to identify, but the following areas of code may be vulnerable:

• Comparisons of user entered values with numeric values.
• Inconsistent expressions. For example, using a combination of if ($x != 0) and if ($x).

Possible Fixes or Improvements

• Validate user input with type-casting operations in mind.
• Use type checking functions like is_long.

Escape or Avoid User Input When Constructing Command Strings

Using functions like exec and eval can add a lot of flexibility to your program. However, caution is necessary to avoid the possibility for users to execute arbitrary commands.

What to Look For

Examine all functions which can execute system commands or PHP code including:

• eval
• preg_replace (when used with the /e modifier this will treat the replacement parameter as PHP code).
• exec
• passthru
• system
• popen
• `` (backticks - can be used to execute commands)

Beyond the Code - A strong security design

The previous steps have all been programming related, but much of an applications security should be determined by a thoughtful design before the programming commences.

Secure application design is a topic in its own right, but some basic tips are listed briefly below.

• Consider using HTTPS for transmission encryption. This can be important even if the privacy of your data is not a priority; eavesdroppers could obtain password or session identifiers and then use these to bypass your application's security.
• Consider restricting access to sensitive pages based on host/domain name or IP address. This can be done using the web server features such as Apache's .htaccess files or by checking variables in your PHP script such as $REMOTE_ADDR.
• Use existing security packages for authentication such as PHPLib.

Conclusion

All languages have security weak points, but with close scrutiny focusing on those weak points many security holes can be avoided. Following the steps in this article as part of everyday coding and formal code reviews should help provide more secure applications.

References

• A Study In Scarlet - Exploiting Common Vulnerabilities in PHP Applications - Shaun Clowes, SecureReality
• Security flaws in PHP - Jo Henrik Endrerud, zez.org
• PHP Manual - Stig Sæther Bakken, et al, PHP.

Clancy Malcolm is a private web application consultant and contributes to numerous open source projects.

oreillynet.com Copyright © 2003 O'Reilly & Associates, Inc.