What is File Upload Vulnerability?

File upload vulnerabilities are vulnerabilities arises when a web server allows users to upload files without sufficiently validating things like their name, type, contents, or size. Failing to properly enforce restrictions on these could mean that even a basic image upload function can be used to upload arbitrary and potentially dangerous files instead. This could even include server-side script files that enable remote code execution.

In some cases, the act of uploading the file is in itself enough to cause damage. Other attacks may involve a follow-up HTTP request for the file, typically to trigger its execution by the server.

Impact of File Upload Vulnerability

In the worst case scenario, the file’s type isn’t validated properly, and the server configuration allows certain types of file (such as .php and .jsp) to be executed as code. In this case, an attacker could potentially upload a server-side code file that functions as a web shell, effectively granting them full control over the server.

If the filename isn’t validated properly, this could allow an attacker to overwrite critical files simply by uploading a file with the same name. If the server is also vulnerable to directory traversal, this could mean attackers are even able to upload files to unanticipated locations.

Failing to make sure that the size of the file falls within expected thresholds could also enable a form of denial-of-service (DoS) attack, whereby the attacker fills the available disk space.

Ways to exploit Web server serving static files

• If this file type is non-executable, such as an image or a static HTML page, the server may just send the file’s contents to the client in an HTTP response.
• If the file type is executable, such as a PHP file, and the server is configured to execute files of this type, it will assign variables based on the headers and parameters in the HTTP request before running the script. The resulting output may then be sent to the client in an HTTP response.
• If the file type is executable, but the server is not configured to execute files of this type, it will generally respond with an error. However, in some cases, the contents of the file may still be served to the client as plain text. Such misconfigurations can occasionally be exploited to leak source code and other sensitive information.

The Content-Type response header may provide clues as to what kind of file the server thinks it has served. If this header hasn't been explicitly set by the application code, it normally contains the result of the file extension/MIME type mapping.

Example of exploiting the File Upload vulnerability

Let us assume that the back end server is serving the php files and it has the file upload functionality, which is not validating the file type or file content. Now we have uploaded a php file named attack.php

The content of attack.php is <?php echo file_get_contents('/path/to/target/file'); ?>

Once uploaded, sending a request for this malicious file will return the target file’s contents in the response.

A more versatile web shell may look something like this:

<?php echo system($_GET['command']); ?>

This script enables us to pass an arbitrary system command via a query parameter as follows:

GET /example/attack.php?command=id HTTP/1.1

Types of exploiting flawed validation of file uploads

• Flawed file type validation
• Preventing file execution in the user-accessible directories
• Insufficient black listing of dangerous files.
• Flawed validation of file content
• File upload race condition
• Uploading the files using PUT method

Exploiting file upload vulnerabilities without remote code execution

• Uploading malicious client-side script
• Exploiting vulnerabilities in the parsing of uploaded files

Note: This article will act as a checklist while hunting for bugs. The detailed explanation will be given in another article.

How to prevent file upload vulnerabilities

Allowing users to upload files is commonplace and doesn’t have to be dangerous as long as you take the right precautions. In general, the most effective way to protect your own websites from these vulnerabilities is to implement all of the following practices:

• Check the file extension against a whitelist of permitted extensions rather than a blacklist of prohibited ones. It’s much easier to guess which extensions you might want to allow than it is to guess which ones an attacker might try to upload.
• Make sure the filename doesn’t contain any substrings that may be interpreted as a directory or a traversal sequence (../).
• Rename uploaded files to avoid collisions that may cause existing files to be overwritten.
• Do not upload files to the server’s permanent filesystem until they have been fully validated.
• As much as possible, use an established framework for preprocessing file uploads rather than attempting to write your own validation mechanisms.