Rich Cannings recently documented Flash-based XSS, clarifying with some examples the quite fuzzy coverage this issue received so far.
Its “The Fix / Users” section says:
Update to the latest version of Flash Player plugin. This will protect users from attacks using the “asfunction” protocol handler
Unfortunately, the majority of the examples listed right there do not use the “asfunction” protocol handler at all!
More realistically, Jeremiah Grossman writes:
- Users update their Flash player – Based on the nature of the issue, I’m not certain of how much benefit to this there is, but might as well patch anyway if there is one available.
- Disable or block Flash content – I think most people reading this probably already do some form of Flash blocking, but for everyone else, there are simply not going to.
Now, the “some form of Flash blocking” Jeremiah’s talking about is most likely NoScript, which:
- Blocks Flash (and other plugins) by default when the content comes from an untrusted web site
- Blocks Flash (and other plugins) by default when content from a trusted website is embedded in an untrusted page - this prevents embedded Flash XSS
- Checks cross sites requests for script injection and sanitizes them as needed - this prevents reflected XSS, included the Flash variants
The best thing, making this approach much more viable than “disabling Flash content” tout-court, is that you can allow individual blocked content pieces with a click, having a chance to examine their types and full addresses before running them: this is what may save you from being owned in a Flash ;)