ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Ten Security Checks for PHP, Part 2

by Clancy Malcolm
04/03/2003

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

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

Related Reading

Web Programming CD Bookshelf
Six Bestselling Books on CD-ROM
By A publication of O'Reilly Media

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

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:

user_id value password value Output Output Correct?
4 x Invalid User ID Yes
1 y Password invalid Yes
1 password1 You are an authenticated user Yes
0 - You are a guest user Yes
a z You are an authenticated user No
00 z You are an authenticated user No

What to Look For

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

Possible Fixes or Improvements

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:

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.

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

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


Return to the PHP DevCenter.

Copyright © 2009 O'Reilly Media, Inc.