Skip to main content
  1. Blog Posts/

Unrestricted File Upload

··1152 words·6 mins

Guide 06 in Sarah’s Welcome to Web Security Series #

In this series, Sarah discusses some common vulnerability classes found in web security and how you can find and exploit them. Today’s focus is unrestricted file upload, which can cause significant damage to an application, depending on what kind of file the attacker uploads.

Introduction #

As one might expect, unrestricted file uploading capabilities make for an easy target for attackers as they can upload malicious files (notably scripts, which can have devastating consequences). Attacks can be as simple as uploading a file with the same name as another critical file or having to bypass a number of defences such as filters and validation checks. Given the possible severity of an attack and obvious risk, it is no surprise that developers take care to try to restrict what files a user can upload, though they are not always successful.

Finding Unrestricted File Upload Vulnerabilities #

Unsurprisingly, file upload abilities can occur whenever a user can upload a file to the server. Common instances of this are websites that let you upload an image for a profile picture or websites that require you to upload some form or document. The more important question is what defences have been implemented. It is very rare for upload systems to be completely undefended. Rather, it is more likely that defences have been implemented but in an unrobust way that can be bypassed or manipulated by an attacker. In order to determine if the system is secure or not, an attacker has no choice but to try a combination of attacks until one is successful or they exhaust all possibilities. This process can technically be automated but the underlying principle is the same: throw pasta at the wall and see what sticks.1

Exploiting Unrestricted File Upload Vulnerabilities #

There are two stages in exploiting a file upload vulnerability. Firstly, an attacker must bypass any defences that may prevent them from uploading malicious files. Secondly, a suitable payload (i.e. the file that will be uploaded) needs to be crafted. Often, this is a webshell or some other malicious script.2

To succeed in the first step, an attacker must have identified all the defences that could prevent them from uploading their payload. There are a myriad of possible defences, each with at least one way to bypass it. To keep things simple, here are some simple restrictions and how an attacker could get around them:

DefenceBypass Method(s)
Restrict the type of file that can be uploaded (can be through a whitelist, blacklist, Content-Type header, etc)Some extensions may have been overlooked

Double extensions may be permitted (particularly in Apache systems)

Mixed case extensions could be used

Content-Type header can be modified in the POST request

Extension detection techniques can be bypassed in a variety of ways

Null character can bypass extension checks

And moreā€¦
Use a file type detectorCan be bypassed with a well-written exploit

Storing code in comments can lead to a bypass

Code can be obfuscated to evade code-detection patterns

File can create the payload, rather than being the payload itself
Verify an image has been uploaded using getimagesize()If you configure it wrong, there’s a dozen ways to get around it
Place the uploaded file in a non-accessible part of the filesystemPath traversal can be used to bypass this defence

This list is non-exhaustive because there are many possible defences and even more bypasses as this OWASP guide demonstrates.

Once an attacker is able to upload any file of their choosing, a suitable payload can be created and uploaded. As aforementioned, webshells are a common payload and while some may prefer to write their own, it is possible to download a number of webshells and Kali Linux’s default package even contains a number of webshells that require only a little bit of modification to use. With a webshell in place, an attacker can proceed to compromise the system in any number of ways. Of course, webshells are not the only possible payloads. Smaller, simpler scripts can be used if an attacker has a very specific goal in mind, such as the retrieval of one user’s credentials.

Defending Against Unrestricted File Upload #

Looking at the table above, it might seem that there are no completely secure defence mechanisms to counter file upload vulnerabilities. However, a developer should always bear in mind that these defences are simply generalisations. If implemented correctly and robustly, these defences should be able to ward off malicious actors, except perhaps for the most persistent of attackers. The OWASP has a cheat sheet which details a number of these approaches, as well as some practical guidance on how to make them as secure as possible. Here is a shortened version of their list:

  • Combine input validation with a list of allowed extensions. Be thorough and do not rely on the Content-Type header. Validate the file type
  • Set a filename length limit and a file size limit
  • If appropriate, do not let the user determine the name of the file, have the application generate a suitable name
  • Restrict who can upload files
  • Avoid storing files on the webroot
  • Run the file through a sandbox or antivirus where possible3

Conclusion #

File upload vulnerabilities act as something of a door for more serious vulnerabilities, such as webshells. Because of the nature of webshells, and indeed the nature of files being stored on a filesystem, securing file upload points is essential for good web security. However, malicious actors also recognise the critical nature of these vulnerabilities and so it often becomes a game of whack-a-mole between developers, who try to implement increasingly robust projections, and attackers, who get increasingly creative with their bypasses.

If you are interested in learning more about unrestricted file uploads and web security, the WebSecurity Academy is a fantastic resource. You can create a free account and explore their labs here.


  1. As in Guide 02, please do not waste pasta. ↩︎

  2. A webshell is a malicious script that can do a whole bunch of things (depending on what it has been programmed to do/contain. It’s usually a collection of tools that can access the filesystem), usually with the goal of compromising the application. It’s basically a backdoor into the application. TL;DR: You don’t want a webshell on your server. ↩︎

  3. For those who have never heard the term ‘sandbox’ outside of a playground before, it is essentially an isolated environment where untrusted files can be run without affecting the wider system/platform/application on which the sandbox is run. A sandbox will have very minimal permissions, so even if the file turns out to be malicious, it cannot do any real harm. Think of it as a secure blasting chamber where things can be safely tested without risk of harming anyone, or anything, outside of the room (in theory at least. There are certainly ways to get around sandboxes though it is often quite complex. Here is an example.). ↩︎