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:

1. An attacker creates a malicious Flash (SWF) file
2. The attacker changes the file extension to JPG
3. The attacker uploads the file to victim.com
4. The attacker embeds the file on attacker.com using an 
5. The victim visits attacker.com, loads the file as embedded with the 
6. The attacker can now send and receive arbitrary requests to victim.com using the victims session
7. The attacker sends a request to victim.com and extracts the CSRF token from the response

A payload could look like this:

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.

Another way to remediate issues like this is to host the uploaded files on a separate domain (like websiteusercontent.com).

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 than one way 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 parameter. However, if an attacker uses an entire Flash file as callback, we can use it just like we would use an uploaded file in this attack. A payload could look like this:

tl;dr: Send Content-Disposition headers for uploaded files and validate your JSONP callback names. Or put the uploaded files on a separate domain

And like always, if you want to know if your website has issues like these, try a  scan!

That’s it for now.

Demo:http://0me.me/demo/SOP/CrossDomainDataHijack.html

FlashDemo:http://pastebin.com/6Yy4UJ3F

SlideShareDoc:http://www.slideshare.net/kuza55/same-origin-policy-weaknesses-1728474#btnNext

Written by: ,