Maybe you should have read the whole article. Cross-site scripting is never mentioned, and seeing how Mike Bailey, the researcher in question, won $10,000 with a Cross-site scripting attack, I think he probably knows the difference

This is a flash attack, dealing with content ownership and poor security controls on flash's part. The end result can indeed be cross-site scripting, but that's not a requirement, and actionscript has different capabilities than javascript.

That really isn't a stretch- most XSS and CSRF exploits work the same way. It just requires that the user be logged into victim.com and click a link to evil.com.

It isn't to imply that the patent itself was ridiculous (Though it is. The patent makes it sound much neater than it is: a carboard sleeve for insulating your coffee cup from your hand).

I really just found that bit of verbiage humorous... the need to define the cup, and the wording used to do so. I recognize that it is necessary in this type of thing, but that doesn't make it less funny.

Keeping user content and applications separate isn't ever a bad idea, because you never know when something like this will come up, and some websites do it for that reason alone. That said, they also commonly do it for performance/caching, disk space, and ease-of-integration.

Off the top of my head, here are a few possible changes:

1. Deny connections by default, unless the server specifically says "this application can connect" (This is already how adobe determines policies on remote servers. It would not be so hard to make the object's origin follow the same rules)
2. Check whether the content-type headers of the server delivering the object actually match those of a flash object, preventing the content overloading attacks described in the paper.
3. Implement a signing policy, so that unsigned flash objects are not given permission to access the server.
4. Run embedded flash objects in the context of the page they are embedded in, rather than that of the origin server. (Flash objects accessed directly, like javascript run through the javascript: uri handler, have no permissions)

Maybe not ideal, but a hell of a lot better than having everybody vulnerable by default, and expecting the server administrators to fix it for them on a case by case basis.

And if you allow me to upload a zip file to your site, will you strip out the swf file that's prepended to it? This is key: It's still a perfectly-formatted zip file.

You may start checking for prepended swf files now, but you sure as hell weren't yesterday.

How exactly is this FUD?

And meanwhile, the attackers are using the ridiculously arcane attack vectors to compromise systems. Seems like it'd be useful to have some people that understand them on the good guys' side.

Browsers do use MIME type to decide on the parser, except with embed tags, where they use the content-type attribute of the embed tag to decide which plugin to invoke.

The plugin, in turn, *should* check the MIME type to determine whether the file it's loading is valid. The Flash plugin does not.

On the other hand, the more arcane the attack, the less likely it is to get fixed, and so the more websites remain vulnerable. The end result is that an attacker well-versed in a variety of obscure attacks can find a way into just about everything.

This one, though, does affect an awful lot of sites- it's rare to find a site that doesn't allow users to upload some kind of file. The impression I get is that image uploads may be more or less simple to validate, but most other filetypes aren't.

If you can write an SWF that can be executed to compromise a website, despite the fact that it looks like, acts like, and in fact is a valid MS Word document, I'd call that a problem.

Your JAR example is actually a pretty good one... as TFA mentions, a similar attack with JAR files that looked like GIFs came out in 2008. Sun fixed their plugin.

In this case, it was used to log the user into the attacker's account, which contained the malicious SWF uploaded as an attachment. If the user then logged into gmail (the video uses a registration email to prompt the user to do so), his account would be compromised.

In Gmail's case, there are other privacy consequences to the login CSRF. For example, if the user is logged into an account that I have access to, I can actually view his google search history.

You'd think so, but you'd be wrong. Embedded content can specify the content-type in HTML (in order for the browser to know what plugin to use to load that content), and Flash trusts that declaration, not the content-type supplied by the server. A properly-designed plugin should trust the server, not the HTML that calls it.

If you can pull it off, you deserve to be as BOFHy as possible.

Unless the explanation itself is emailed to them and contains a secondary attack... if they really did it with XSS as the ZDNet article states, that's a reasonable assumption.

But we may be bordering on ridiculous.