Security Considerations

Along with the ability to work with files and permitting users to upload their own files to the server come a number of important security considerations. Although we have tried to demonstrate good security practices in all of our samples thus far, we list the security considerations here again for extra clarity.

File Access Considerations

We will face a few major security concerns when using PHP functions to access, create, and manipulate files on the local file systems of our server.

User Data as Filenames

Suppose we have a list of files with specifications in them on our hard disk. For example, we might have a copy of many of the major Internet RFCs in a directory called rfc/. To let a user see the contents of one of these, we might choose to write code such as the following:

   $contents = file_get_contents('rfc/' . $_POST['showme']);   if ($contents === FALSE)     throw new FileAccessException('rfc/' . $_POST['showme']);   echo <<<EORFC   The Requested RFC is as follows:<br/>   <br/>   $contents EORFC; 

The problem with this file is if the user inputs into the showme field of the POST data the value '../../../etc/passwd' or some similar value. Because of relative paths, we have effectively enabled the user to view any file on the file system. It might take a few tries to get the exact relative path, but the user eventually will.

The best way to prevent this sort of security breach is just to never use user input as a filename. When designing your application, try to come up with other means of putting together the system so that you can map requests to files (or better yet, database content) without directly using user input.

If you are working with an application that already has such a system in place and are seeking to make it more secure, however, just reject any user input that contains a forward slash (/), backslash (\), or drive letter (m:). You can do this with the strpos function or the ereg function shown in Chapter 22, "Data Validation with Regular Expressions."

 // ereg version function is_filename_safe($in_filename) {   // look for string starting with letter: OR   // containing anywhere a forward- or backslash.   if (ereg('(^[a-zA-z]:|[\\\/])+', trim($in_filename)))     return FALSE; // unsafe   else     return TRUE;  // safe } // strpos version function is_filename_safe2($in_filename) {   if (strpos($in_filename, '/') !== FALSE       or strpos($in_filename,'\\' !== FALSE       or strpos(trim($in_filename), ':') == 1)     return FALSE;   else     return TRUE;   // safe } 

Virtual Hosts and File Visibility

As discussed in Chapter 17, "Securing Your Web Applications: Software and Hardware Security," virtual hosts on a web server present a unique security problem in that, usually, all web sites are operating as the same user. This means that any web site can access the files of any other web site. Therefore, some other virtual host on our server (run by baddies) might try to find interesting files in our web application and view their contents, particularly any that contain database usernames and passwords.

A few key solutions to this problem exist. The first, also discussed in Chapter 17, is to use safe mode whenever possible. Although not a perfect solution to the virtual host problem, it offers a basic level of file security and tries to prevent other web sites from viewing the contents of ours.

Far more effective, if more drastic and restrictive, is if you or the hosting ISP disables the functions or classes (via the disable_functions directive in php.ini) via which scripts can browse the contents of directories, such as opendir, readdir, and the dir class shown elsewhere in this chapter. Although this might cause our scripts some minor inconvenience in having to remember where files are, it helps prevent people from easily learning which files we have.

The Server and File Visibility

As also mentioned in Chapter 17, many web servers happily serve up any file requested of them, especially if they are unaware of its content type. Therefore, if we create a file in our web application directory called userpasswd, with a list of usernames and passwords, and somebody types in his browser


many web servers will duly send that person the contents of this file.

We can solve this problem in two ways. First, we should be sure to put particularly sensitive files in some location other than our public web contents (HTML) directory. Second, we should, as discussed in Chapter 17, make sure that the web server only serves up those files that it is instructed to. Most major web servers enable us to block files with certain names or extensions, which is how we prevent people from viewing the code of our .inc files.

Core Web Application Development With PHP And MYSQL
Core Web Application Development with PHP and MySQL
ISBN: 0131867164
EAN: 2147483647
Year: 2005
Pages: 255

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: