[teraflop]

As the article explains, the problem is that SWF files hosted on one domain can execute in the security context of that domain, even when embedded in a page on a completely different site. So allowing attacker-controlled uploads makes any credentials on that domain, such as session cookies and CSRF tokens, vulnerable. If the SWF is hosted on a domain with no sensitive credentials, this particular problem goes away.

[sp332]

Reminds me of this Google Docs phishing scam, that uses a Google domain to look legit http://www.symantec.com/connect/blogs/google-docs-users-targ...

[tantalor]

Google Drive does let you host arbitrary content, but from googledrive.com, not from google.com.

https://support.google.com/drive/answer/2881970

This is basically the same as github.io.

The Symantec article is interesting but only says the fake page is hosted on "Google's servers", not "google.com", but users might believe "googledrive.com" is trustworthy.

[bsder]

I don't understand. How does serving a flash applet from my domain get you access to anything other than that applet?

I'm not arguing that this attack doesn't exist. I just don't understand what the attacker gets access to.

[teraflop]

Browser security relies on the "same origin policy" which says that certain operations are restricted to only access resources in the same domain as the active page. In particular, you can't read cookies from another domain, and you can't read the responses of authenticated HTTP requests. XSS and CSRF attacks all rely on an circumventing this protection in various ways.

In this case, Flash considers the origin to be the location of the SWF file. This is different from normal JavaScript where all scripts in a page run under that page's origin, no matter where they're loaded from.