Allowing file uploads by end users, peculiarly if done without a full agreement of the risks associated with it, is akin to opening the floodgates for server compromise. Naturally, despite the security concerns surrounding the power for end-users to upload files, it is an increasingly mutual requirement in modern web applications.

File uploads behave a pregnant risk that not many are aware of, or how to mitigate against abuses. Worst notwithstanding, several web applications contain insecure, unrestricted file upload mechanisms. This article will present eight mutual flawed methods of securing upload forms, and how easily an assailant could featherbed such defenses.

No Validation

A uncomplicated file upload form typically consists of an HTML class which is presented to the client and a server-side script that processes the file being uploaded. The post-obit example contains such an HTML grade and a server-side script written in PHP.

                <form enctype="multipart/form-data" action="uploader.php" method="Post">   <input type="subconscious" name="MAX_FILE_SIZE" value="100000" />   Choose a file to upload:   <input name="uploadedfile" blazon="file" />   <input blazon="submit" value="Upload File" />  </form> <?php    $target_path = "uploads/";   $target_path = $target_path . basename($_FILES['uploadedfile']['name']);   if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {     echo "The file " . basename($_FILES['uploadedfile']['name']) . " has been uploaded";    } else {     repeat "In that location was an error uploading the file, please try again";    } ?>

When the PHP interpreter receives an HTTP POST method request of the multipart/form-data encoding type, the script will create a temporary file with a random name in a temporary directory on the server, for example, /var/tmp/php6yXOVs. The PHP interpreter will besides populate the global array $_FILES with the information about the uploaded file every bit follows.

  • $_FILES['uploadedfile']['name']: The original name of the file on the client machine
  • $_FILES['uploadedfile']['blazon']: The mime blazon of the file
  • $_FILES['uploadedfile']['size']: The size of the file in bytes
  • $_FILES['uploadedfile']['tmp_name']: The temporary filename in which the uploaded file was stored on the server

The move_uploaded_file() PHP role volition move the temporary file to a location provided by the user. In this instance, the destination is below the server root. Therefore the files can be accessed using a URL such as http://www.example.com/uploads/uploadedfile.txt.

In this uncomplicated example, no restrictions are imposed by the server-side script on what file types are allowed to exist uploaded to the server. To such an extent, an attacker could hands upload a malicious PHP that could lead to server compromise.

MIME-type Validation

A common mistake fabricated when securing file upload forms is to just cheque the MIME-type returned by the application runtime. For example, with PHP, when a file is uploaded to the server, PHP will set the variable $_FILES['uploadedfile']['type'] to the MIME-type provided by the spider web client.

Since an attacker could hands control the MIME-type by sending the server a crafted HTTP POST request, such validation is trivial for an attacker to bypass. To such an extent, an assaulter could easily upload a malicious PHP file with an allowed MIME-type that could lead to server compromise.

Blacklisting File Extensions

Some other weak validation method that is widely used in file upload forms is to use a blacklist of types of files that have dangerous extensions. Upload forms using this mechanism would cheque the extension of the file that is being uploaded and compare its file extension to a list of extensions that the application considers harmful.

While this could exist somewhat effective against some file types, the choice of employing a blacklist is a poor one since practically impossible to compile a list of all possible file extensions that an attacker could abuse use, especially if the application is running within an environs that allows a large number of scripting languages, such equally Perl, Python, Ruby, and others – the list is countless. For example, the attacker may change the messages in the extension to their upper-case letter forms (.phP, .PhP, .pHP). A whitelisting arroyo in this employ case is by far more constructive.

One possible mode an aggressor could bypass a file extension blacklist on an Apache HTTP Server is to first upload an .htaccess file with the post-obit contents.

                AddType application/10-httpd-php .jpg

The above configuration would instruct the Apache HTTP Server to execute JPEG images as though they were PHP scripts. An assailant would so proceed to upload a file with a .jpg extension (a file extension that is presumably immune), which would contain PHP code instead of an image and this would allow for code execution.

The screenshot below shows an HTTP request to a JPEG file that contains PHP code that invokes the phpinfo() role.

Upload Form files

Double Extensions

Another concept for bypassing file upload validation is for an attacker to abuse double extensions where an application extracts file extensions by looking for the . character in the filename, and extracting the string after the dot graphic symbol. The method used to bypass this approach is similar to the method used to bypass a file extension blacklist.

It's important to first understand how the target web server handles files with multiple extensions. In this instance, information technology shall exist assumed that the target server is the Apache HTTP Server. The following is a quotation of the Apache HTTP Server documentation regarding files with multiple extensions.

Files can accept more 1 extension, and the order of the extensions is normally irrelevant. For example, if the file welcome.html.fr maps onto content type text/html and language French then the file welcome.fr.html will map onto exactly the same data. If more than one extension is given which maps onto the same type of meta-information, then the ane to the right will be used, except for languages and content encodings. For case, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, and so the file welcome.gif.html will be associated with the MIME-type text/html.

Therefore, a file named index.php.123 volition exist interpreted as a PHP file past the Apache HTTP Server and it will exist executed. This, of course, will only work if the final extension (in this case .123) is not specified in the list of MIME-types known to the web server. This lesser-known feature of the Apache HTTP Server could be very dangerous for a number of reasons. Knowing this, an attacker could upload a file containing malicious code (such as a spider web shell) and bypass the file upload form validation.

A far better arroyo to securing file upload forms is to employ a whitelisting approach. With this arroyo, simply files that lucifer a known and accepted file extension are immune. Nevertheless, in some cases, this approach volition not work as expected. For case, when the Apache HTTP Server is configured to execute PHP lawmaking, in that location are 2 ways one can specify this: using the AddHandler directive or using the AddType directive. If the AddHandler directive is used, all filenames containing the .php extension (.php, .php.jpg) will be executed as PHP scripts. Therefore, if an Apache HTTP Server configuration file contains the following, it may be vulnerable:

                AddHandler php5-script .php

On an Apache HTTP Server with the to a higher place configuration, an assaulter tin upload a file named filename.php.jpg, bypass the validation, and execute code.

Checking the Paradigm Header

When image upload only is allowed, most spider web applications ordinarily validate the image header by using a server-side role such as getimagesize() in PHP. When called, this function will return the size of an image. If the file is not a valid epitome, meaning that the file header is non that of an image, the function will return Faux. Therefore, several spider web applications typically check if the function returns TRUE or Imitation and validate the uploaded file using this data.

If an attacker attempts to upload a simple PHP vanquish embedded in a JPEG file, the function volition return simulated, finer stopping the assault. However, fifty-fifty this approach can be easily bypassed if the Apache HTTP Server is using the AddHandler directive described higher up. If an paradigm file is opened in an image editor, such as GIMP, one can edit the image metadata to include a comment. An assailant would insert some PHP code here as shown below.

The epitome volition still take a valid header; therefore information technology bypasses the getimagesize() check. As seen in the screenshot beneath, the PHP code inserted in the image comments nonetheless gets executed when the image is requested by a browser.

Protecting the Upload Folder with .htaccess

Another mutual method used to secure file upload forms is to restrict execution of scripts in an upload directory using .htaccess configuration that would typically contain the following:

                AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi Options –ExecCGI

The above is another type of blacklist approach, which in itself is not very secure. Furthermore, equally warned in the PHP documentation, the move_uploaded_file() function will overwrite any file if the destination file already exists. Because uploaded files can and will overwrite the existing ones, an attacker could easily supersede an existing .htaccess file with a modified one. This will allows execution of specific scripts which can help compromise a server.

Client-Side Validation

Another mutual security mensurate in file upload forms is customer-side validation of files to exist uploaded. Typically, such an approach is more than mutual in ASP.Internet applications, since ASP.Net offers easy-to-utilize validation controls.

These types of validation controls allow an application to do regular-expression checks upon the file that is being uploaded, to cheque that the extension of the file beingness uploaded is specified in the listing of allowed extensions. Beneath is a sample code taken from Microsoft'southward website.

                <asp:FileUpload ID="FileUpload1" runat="server" /><br />  <br />  <asp:Push button ID="Button1" runat="server" OnClick="Button1_Click"  Text="Upload File" /> <br />  <br />  <asp:Label ID="Label1" runat="server"></asp:Label>  <asp:RegularExpressionValidator  id="RegularExpressionValidator1" runat="server"  ErrorMessage="Only mp3, m3u or mpeg files are allowed!"  ValidationExpression="^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\due west[\due west].*))  +(.mp3|.MP3|.mpeg|.MPEG|.m3u|.M3U)$"  ControlToValidate="FileUpload1"></asp:RegularExpressionValidator>  <br />  <asp:RequiredFieldValidator  id="RequiredFieldValidator1" runat="server" ErrorMessage="This is a required field!"  ControlToValidate="FileUpload1"></asp:RequiredFieldValidator>

This ASP.NET code uses validation controls, and then the end-user is merely allowed to upload .mp3, .mpeg or .m3u files to the web server. If the file blazon does not match whatsoever of the specified extensions, the validation control throws an exception and the file won't be uploaded.

Since this type of validation is done on the client side, a malicious user can easily bypass information technology. It is possible to write a brusque client-side script that will exercise the validation instead of the script provided by the spider web application. Without using a spider web browser, the aggressor can ship HTTP Post requests to the application in lodge to bypass the client side validation and upload a malicious file.

Suggested Solution

The following is a list of all-time practices that should be enforced when file uploads are allowed on websites and web applications. These practices will assistance avert file upload vulnerabilities in web applications that are served using Apache HTTP Server, however like rules could easily be applied to other servers both on Linux and Windows.

  • Define an .htaccess file that volition only allow access to files with allowed extensions.
  • Exercise not place the .htaccess file in the same directory where the uploaded files volition be stored, instead, place it in the parent directory. This style the .htaccess file can never exist overwritten by an attacker.
  • A typical .htaccess which allows just GIF, JPG, JPEG, and PNG files should include the following (this should be adapted as necessary for specific requirements). The post-obit will too forestall double extension attacks: 
                        deny from all < files ~ "^w+.(gif|jpe?m|png)$">  gild deny,permit allow from all  </files>
  • If possible, upload the files in a directory exterior the server root.
  • Forestall overwriting of existing files (to prevent the .htaccess overwrite attack).
  • Create a whitelist of accepted MIME-types (map extensions from these MIME-types).
  • Generate a random file name and add the previously generated extension.
  • Don't rely on customer-side validation only, since information technology is non enough. Ideally, both server-side and client-side validation should exist implemented.

Oft asked questions