Critical vulnerabilities exist in a large number of widely used web authoring tools that automatically generate Shockwave Flash (SWF) files, such as Adobe (r) Dreamweaver (r), Abobe Contribute (r), Adobe Acrobat (r) Connect (tm) (formerly Macromedia Breeze), InfoSoft FusionCharts, and Techsmith Camtasia. The flaws render websites that host these generated SWF files vulnerable to Cross-Site Scripting (XSS).
This problem is not limited to authoring tools. Autodemo, a popular service provider, used a vulnerable controller SWF in many of their projects.
Simple Google hacking queries reveal that hundreds of thousands of SWFs are vulnerable on the Internet, and a considerable percentage of major Internet sites are affected. We are only reporting XSS vulnerabilities that have been fixed by the vendors.
Cross Site Scripting
Getting someone to click on a link is easy, just check out this example.
XSS Vulnerabilities in Common SWFs
Websites hosting SWFs generated by these products are vulnerable to XSS. Examples include popular government, banking, social networking, and web mail sites.
We were unable to perform an exhaustive review of all authoring tools that generate SWFs. More XSS issues may exist in the products listed below and certainly exist in other applications that save to SWF.
We are only reporting XSS vulnerabilities that have been fixed by the vendors. There are more products vulnerable. We will publish more information when the vendor releases fixes.
Adobe Dreamweaver and Contribute The "skinName" parameter is accepted by all Flash files produced by the "Insert Flash Video" feature. "skinName" can be used to force victims to load of arbitrary URLs including the "asfunction" protocol handler:
InfoSoft was contacted on September 2, 2007. Fixes for all issues we found were released in late September. Webmasters should consult InfoSoft to properly upgrade their SWFs. See "The Fix" for details.
One of the issues found in Camtasia was that the "csPreloader" parameter loads an arbitrary flash file:
Techsmith was contacted on August 12, 2007. Fixes for all issues was released late September. Webmasters should contact Techsmith to properly upgrade their SWFs. See "The Fix" for details.
Autodemo was contacted on August 17, 2007. Autodemo was extremely responsive to our report and quickly fixed the issue in August. Webmasters must update to the latest "control.swf". See "The Fix" for details.
Autodemo is not the only service provider to have XSS in their products. They are just the only service provider we looked at. Readers should be concerned about other service providers who don't even know their SWFs are vulnerable.
All of the measures below should be taken:
Update to the latest version of Flash Player plugin. This will protect users from attacks using the "asfunction" protocol handler
All vulnerabilities reported above have been fixed, so please:
Remove vulnerable SWFs from your website
Follow the manufacturers’ advice on republishing your SWFs
Techsmith - Camtasia Studio users can upgrade to Camtasia Studio version 5 to obtain a version which creates SWF files that do not have this vulnerability (visit http://www.techsmith.com). Users who are concerned about this vulnerability can regenerate their SWF content with Camtasia Studio version 5.
It is likely that other authoring tools that automatically generate SWFs can be used for XSS attacks. We highly recommend that website owners serve automatically generated SWFs from numbered IP addresses or from "safe" domains (i.e. domains that contain no sensitive cookies or domains that cannot be used for phishing)
Depending on the impact of XSS on a given website, website owners may want to even consider moving or removing all third-party generated SWFs
Flash Authoring Tools Developers and All Flash Developers Flash based XSS is not limited to authoring tools. Unfortunately, common design patterns used in many Flash applications introduce XSS issues, so all Flash developers, including Flash authoring tools developers, should do the following:
Test your SWFs with Stafano Di Paola's SWFIntruder. If you don't, others will.
Perform proper input validation on all user definable variables used in URL loading functions and the "htmlText" fields. For example:
Where possible, whitelist protocol handlers to only allow "http:" and "https:" in all functions that require URLs
When using "getURL()", whitelist user definable input (e.g, only allow alphanumeric characters). Do not rely on the "escape()" function.
Depending on the context, whitelist, URL encode, and/or HTML entity encode user input in "htmlText" fields
Within your Flash applications, load supporting SWF files, images, and sounds from relative URLs. Disallow absolute URLs. Be aware of open redirectors on your site. Consider rejecting relative URLs containing "..", ".%2e", etc. that attackers could use to traverse to open redirectors.
Detailed Flash hacking techniques and solutions are thoroughly discussed in "Hacking Exposed Web 2.0: Web 2.0 Security Secrets and Solutions"
Read Adobe's "Creating more secure SWF web applications" document.
First and foremost, we thank Stafano Di Paola of Minded Security and Obscure of EyeonSecurity who thoroughly researched and pioneered every attack we used.
Thanks to Autodemo, Infosoft, and Techsmith for quickly fixing this issue. We also thank the Computer Emergency Response Team for coordinating with the vendors to fix this issue, the Adobe Flash player development teams for including some fixes in the player (we hope to see more in the future), the Adobe Software Security Engineering Team, and the Google Security Team for giving me time to pursue this research and coauthor a book.