Content Sniffing is one attack with similar characteristics:
Many HTTP servers supply a Content-Type that does not match the actual contents of the response. If an attacker manipulates the content in a way to be accepted by the web app and rendered as HTML by the browser, it is possible to inject malicious code.
Web App prevent this type of an attack by checking that an uploaded jpeg file contains the correct Content-Type ‘image/jpeg’ and the ‘NoSniff’ header in place.
These prevention’s do not matter when it comes to Flash plugins. 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 normal Flash file.
The embedded flash file can still communicate with its source domain without checking the cross-domain policy. If the Flash file sends requests, it will be allowed to read files from the domain of VictimDomain.com.
Basically meaning that if a website allows file uploads without validating the content of the file (Parse), an attacker can bypass any CSRF protection on the website.
- Attacker creates a malicious Flash file (SWF) and then changes the file extension to JPG
- The attacker uploads the file to VictimDomain.com
- The attacker embeds the file on AttackerDomain.com
- The victim visits VictimDomain.com, loads the file
- Attacker can now send and receive arbitrary requests to VictimDomain.com
- Implement the Content-Disposition header so that Flash won’t execute the file: Content-Disposition: attachment; filename=”image.jpg”
- Parse the file to determine its content as well as sending a Content-Disposition header where applicable.
- If possible isolate the domain of the uploaded files.