The lesser known pitfalls of allowing file uploads on your website

These days a lot of websites allow users to upload files, but many don’t know about the unknown pitfalls of letting users (potential attackers) upload files, even valid files.

What’s a valid file? Usually, a restriction would be on two parameters:

The uploaded file extension

The uploaded Content-Type

For example, the web application could check that the extension is “jpg” and the Content-Type “image/jpeg” to make sure it’s impossible to upload malicious files. Right?

The problem is that plugins like Flash doesn’t care about extension and Content-Type. If a file is embedded using an <object> tag, it will be executed as a Flash file as long as the content of the file looks like a valid Flash file.

But wait a minute! Shouldn’t the Flash be executed within the domain that embeds the file using the <object> tag? Yes and no. If a Flash file (bogus image file) is uploaded on victim.com and then embedded at attacker.com, the Flash file can execute JavaScript within the domain of attacker.com. However, if the Flash file sends requests, it will be allowed to read files within the domain of victim.com.

This basically means that if a website allows file uploads without validating the content of the file, an attacker can bypass any CSRF protection on the website.

The attack

Based on these facts we can create an attack scenario like this:

An attacker creates a malicious Flash (SWF) file

The attacker changes the file extension to JPG

The attacker uploads the file to victim.com

The attacker embeds the file on attacker.com using an <object> tag with type “application/x-shockwave-flash”

The victim visits attacker.com, loads the file as embedded with the <object> tag

The attacker can now send and receive arbitrary requests to victim.com using the victims session

The attacker sends a request to victim.com and extracts the CSRF token from the response

The fix

The good news is that there’s a fairly easy way to prevent Flash from doing this. Flash won’t execute the file if it sends a Content-Disposition header like so:

Content-Disposition: attachment; filename=”image.jpg”

So if you allow file uploads or printing arbitrary user data in your service, you should always verify the contents as well as sending a Content-Disposition header where applicable.

Other uses

But the fun doesn’t stop at file uploads! Since the only requirements of this attack is that an attacker can control the data on a location of the target domain (regardless of Content-Type), there’s more ways to perform this attack.

One way would be to abuse a JSONP API. Usually, the attacker can control the output of a JSONP API endpoint by changing the callback of the current location. There’s no Cross-Site Scripting issue because the server will send Content-Type “application/json”. However, if an attacker uses an entire Flash file as callback and embeds that URL on their domain using the <object> tag, we have the same outcome. A payload could look like this: