Section 2.3. File Upload Attacks

2.3. File Upload Attacks

Sometimes you want to give users the ability to upload files in addition to standard form data. Because files are not sent in the same way as other form data, you must specify a particular type of encodingmultipart/form-data:

     <form action="upload.php" method="POST" enctype="multipart/form-data"> 

An HTTP request that includes both regular form data and files has a special format, and this enctype attribute is necessary for the browser's compliance.

The form element you use to allow the user to select a file for upload is very simple:

     <input type="file" name="attachment" /> 

The rendering of this form element varies from browser to browser. Traditionally, the interface includes a standard text field as well as a browse button, so that the user can either enter the path to the file manually or browse for it. In Safari, only the browse option is available. Luckily, the behavior from a developer's perspective is the same.

To better illustrate the mechanics of a file upload, here's an example form that allows a user to upload an attachment:

     <form action="upload.php" method="POST" enctype="multipart/form-data">     <p>Please choose a file to upload:     <input type="hidden" name="MAX_FILE_SIZE" value="1024" />     <input type="file" name="attachment" /><br />     <input type="submit" value="Upload Attachment" /></p>     </form> 

The hidden form variable MAX_FILE_SIZE indicates the maximum file size (in bytes) that the browser should allow. As with any client-side restriction, this is easily defeated by an attacker, but it can act as a guide for your legitimate users. The restriction needs to be enforced on the server side in order to be considered reliable.

The PHP directive upload_max_filesize can be used to control the maximum file size allowed, and post_max_size can potentially restrict this as well, because file uploads are included in the POST data.

The receiving script, upload.php, displays the contents of the $_FILES superglobal array:

     <?php     header('Content-Type: text/plain');     print_r($_FILES);     ?> 

To see this process in action, consider a simple file called author.txt:

     Chris Shiflett     http://shiflett.org/ 

When you upload this file to the upload.php script, you see output similar to the following in your browser:

     Array     (         [attachment] => Array             (                 [name] => author.txt                 [type] => text/plain                 [tmp_name] => /tmp/phpShfltt                 [error] => 0                 [size] => 36             )     ) 

While this illustrates exactly what PHP provides in the $_FILES superglobal array, it doesn't help identify the origin of any of this information. A security-conscious developer needs to be able to identify input, and in order to reveal exactly what the browser sends, it is necessary to examine the HTTP request:

     POST /upload.php HTTP/1.1     Host: example.org     Content-Type: multipart/form-data; boundary=----------12345     Content-Length: 245     ----------12345     Content-Disposition: form-data; name="attachment"; filename="author.txt"     Content-Type: text/plain     Chris Shiflett     http://shiflett.org/     ----------12345     Content-Disposition: form-data; name="MAX_FILE_SIZE"     1024     ----------12345-- 

While it is not necessary that you understand the format of this request, you should be able to identify the file and its associated metadata. Only name and type are provided by the user, and therefore tmp_name, error, and size are provided by PHP.

Because PHP stores an uploaded file in a temporary place on the filesystem (/tmp/phpShfltt in this example), common tasks include moving it somewhere more permanent and reading it into memory. If your code uses tmp_name without verifying that it is in fact the uploaded file (and not something like /etc/passwd), a theoretical risk exists. I refer to this as a theoretical risk because there is no known exploit that allows an attacker to modify tmp_name. However, don't let the lack of an exploit dissuade you from implementing some simple safeguards. New exploits are appearing daily, and a simple step can protect you.

PHP provides two convenient functions for mitigating these theoretical risks: is_uploaded_file( ) and move_uploaded_file( ). If you want to verify only that the file referenced in tmp_name is an uploaded file, you can use is_uploaded_file( ):

     <?php     $filename = $_FILES['attachment']['tmp_name'];     if (is_uploaded_file($filename))     {       /* $_FILES['attachment']['tmp_name'] is an uploaded file. */     }     ?> 

If you want to move the file to a more permanent location, but only if it is an uploaded file, you can use move_uploaded_file( ):

     <?php     $old_filename = $_FILES['attachment']['tmp_name'];     $new_filename = '/path/to/attachment.txt';     if (move_uploaded_file($old_filename, $new_filename))     {       /* $old_filename is an uploaded file, and the move was successful. */     }     ?> 

Lastly, you can use filesize( ) to verify the size of the file:

     <?php     $filename = $_FILES['attachment']['tmp_name'];     if (is_uploaded_file($filename))     {       $size = filesize($filename);     }     ?> 

The purpose of these safeguards is to add an extra layer of security. A best practice is always to trust as little as possible.