Link Search Menu Expand Document

Unrestricted File Upload

  1. Unrestricted File Upload
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing

Description

Unrestricted File Upload vulnerability occurs due to insufficient or improper file-type validation controls being implemented prior to files being uploaded to the web application. Without these methods of validation in place, a malicious actor may be able to craft the upload request to bypass the application-layer defenses and potentially lead to full system takeover.

The OWASP Top 10 refers to Unrestricted File Uploads as a significant risk, and for good reason. This particular stone in a potential chain of escalating steps is often the primary one, assisting an attacker to execute the maliciously crafted code that they have been able to inject into the target system.

Impact

The impact of an Unrestricted File Upload vulnerability is usually high given the fact it facilitates code execution on target systems and web applications. Malicious actor might be able to escalate this to complete access by uploading and executing a web-shell that can run commands, attack other servers, and be used as a staging point to pivot to other clients in the network.

In 2017, a security researcher participating in a bug bounty run by PayPal was able to leverage an Unrestricted File Upload vulnerability to execute remote code on the application. Companies of this size regularly run bug bounties to continually test their defenses for weaknesses, financially enticing security researches to identify and report bugs before malicious actors are able to exploit the same bugs. However, this is still an after-the-fact solution to a systemic problem that arises far earlier in the development cycle at the implementation stage.

Elaborating on the impacts, Unrestricted File Uploads can lead to Code and subsequentlly Command Injection, XSS attacks, Denial of service attacks, the creation of phishing pages, and other kind of attacks depending on the application technology and the uploaded file type.

Scenarios

Unrestricted File Upload vulnerabilities can be exploited in a variety of methods depending on the language used and the specific flaw exposed under the umbrella of the overall vulnerability. There are generally existing countermeasures and validations in place; however, sometimes they aren’t implemented at all or they are, yet poorly. The following are examples of preventive measures that can be bypassed:

  • MIME-type validation
  • Checking the file extension against a deny list
  • Image header checks

The following elaborates on Unrestricted File Upload manipulation as a result of non-existent validations in a PHP script.

A user is authorised by the following code to upload a picture of a flag (a SecureFlag picture even!) to the web server. The HTML code that facilitates the user end form has a type file input field.

<form action="upload_flagpics.php" method="post" enctype="multipart/form-data">

  Choose a file to upload:
  <input type="file" name="filename"/>
  <br/>
  <input type="submit" name="submit" value="Submit"/>

</form>

Upon submission, the form then sends the file to upload_flagpics.php on the web server. The file is stored in a temporary location by PHP until it is either retrieved or discarded by code on the server side. The file is then sent to a more permanent directory called flagpics/.

// Define the target location where the secureflag picture being
// uploaded is going to be saved.

$target = "flagpics/" . basename($_FILES['uploadedfile']['name']);

// Move the uploaded file to the new location.
if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target))
{
	echo "The picture has been successfully uploaded.";
}
else
{
	echo "There was an error uploading the picture, please try again.";
}

Unfortunately, the above code does not validate the file type being uploaded, and if the flagpics/ directory is accessible in the web document root, a malicious actor would be able to upload a file with the name malicious.php. This filename, ending in .php, can then of course be executed by the web server. Thus, a malicious actor could additionally send:

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

If this file is successfully installed by the attacker, they will be able to run arbitrary commands using a URL to execute, such as:

http://www.vulnerableapp.com/upload_dir/malicious.php?cmd=ls%20-l

thus running the ls -al command.

Prevention

Developers must review upload functionality to determine if uploaded content is ever returned to other application users, whether that be via normal application usage or attack manipulation. As a part of this revision, developers should consider:

  • If the application filters file extensions and the MIME type of the uploaded file.
  • If placing executable JavaScript or HTML into the file is possible.
  • The header information returned after the contents of a file are downloaded.
  • If the storage location for uploaded content is escapable with a crafted filename.

There are numerous steps toward a more robust upload code architecture that developers must consider in their design:

  • Developers must use an allow list, enforcing acceptance of only listed, non-executable file extensions.
  • Developers should ensure file names do not contain directory traversal characters such as ../ that are used to place files outside of designated directory locations.
  • Developers should alter permissions on the upload folder to ensure the files can’t be executed.
  • Uploads must not be placed in directories that are accessible from the web.
  • Developers should ensure that if uploaded files are downloaded by users, they contain X-Content-Type-options: nosniff header and a Content-Disposition header that indicates browsers to handle files as an attachment
  • Uploaded files should be subject to immediate virus scanning.
  • Developers must enforce size limits on uploaded files and reject archive formats (like ZIP) from being uploaded at all.

Testing

Verify that user-uploaded files are stored outside in designated directories outside of the web root, or, if required to be displayed or downloaded from the applicationm, are served by either octet stream downloads or from an unrelated domain.


Table of contents