Crossdomain.xml security warning

Chris Shiflett and I recently researched a security flaw in sites that host liberal crossdomain.xml policy files in a domain also serving UI pages. It turned out that there is indeed a pitfall to be aware of and Flickr was vulnerable.

The exploit is essentially an application of Cross-Site Request Forgery (CSRF) with a twist of Flash.

Usually, CSRF attacks are mitigated by including a formkey (or canary) in the page that is allowed to initiate POST requests. If the formkey is missing, expired or otherwise incorrect, the POST fails. This normally prevents CSRF attacks, because the browser would not allow another domain from reading the formkey out of a page (because of the same domain policy).
That is where Flash comes into play.

As I've shown with FlashXMLHttpRequest, you can use Flash to make arbitrary GET and POST requests to any domain that hosts the proper crossdomain.xml file. Usually this file is posted in a domain that hosts web services, to make them accessible from Flash. But if that domain also contains some UI, another CSRF protection in this UI becomes useless.

Flickr was vulnerable to this exploit, because it hosted an "allow all" policy file in it's main domains: flickr.com and www.flickr.com.
We notified Flickr and they fixed the hole promptly by moving their APIs to a separate domain and removing the crossdomain.xml file on their main domain (now 404).
So the demonstration exploit page I wrote doesn't work anymore. It showed how to use FlashXMLHttpRequest to bypass the formkey protection in Flickr: any user that would open this page while being logged into his Flickr account would have his Flickr account modified (I would be added to the list of their friends and family).

The bottom line is that in order to keep your UI secure, you shouldn't host it in a domain that has a liberal crossdomain.xml file. Instead, you should serve your APIs which you want to open accross domains from a separate domain.