In a previous blog post, I discussed the insecurity of cross-domain Ajax. In the comments, I referenced a cross-domain Ajax with Flash demonstration created by Julien Couvreur:

My initial observation leads me to believe that the target site has to allow these requests in a file called crossdomain.xml.

Julien replied:

You are correct: cross-site requests in Flash require an explicit opt-in from the server, using crossdomain.xml. That file not only needs to be there, it also needs to identify which foreign domains are allowed to do cross-site requests (which is '*', a wildcard, in most public web sites I've seen so far, like Yahoo, Amazon, etc.).

Yikes! Can you spot the problem? I certainly did. If a web site allows cross-domain Ajax requests initiated from anywhere, it is vulnerable to exactly the types of attacks I was describing. I immediately searched Google for some examples:

http://google.com/search?q=inurl%3Acrossdomain.xml

One of the first results was http://flickr.com/crossdomain.xml. (It no longer exists; keep reading.)

1. <cross-domain-policy>
2.     <allow-access-from domain="*"/>
3. </cross-domain-policy>

Oh no! Not Flickr! Because of this policy, I knew I could make any user of Flickr perform any action of my choosing. As a user of Flickr, I knew I could just as easily be the victim.

One of the people commenting on my post seemed to have a difficult time grasping the concept, so I doubted my ability to describe the problem clearly. Also, because my Flash and JavaScript skills are poor, I knew it would take me a while to develop an exploit. (Exploits tend to be much clearer than explanations.) So, I emailed Julien Couvreur (the author of the Flash demonstration I mentioned), and he graciously agreed to help me develop an exploit to demonstrate the risk. At the same time, I contacted Cal Henderson and tried to explain the vulnerability over IM.

Luckily, Cal understood the vulnerability immediately, so Julien's exploit was unnecessary. However, we still collaborated to create an exploit that was similar to the Myspace worm. Users would automatically add you as a friend (and family, for good measure). Of course, the exploit worked, so the vulnerability was verified. Julien and I plan to write a paper on this particular attack in the near future, primarily to help others avoid making the same mistake.

Flickr has since isolated their API to a separate domain in order to resolve this particular problem. I haven't spent time researching the potential risks of this approach, specifically CSRF attacks that target an API, but at least the primary and obvious problem has been fixed. In addition, Cal was notified on the 11^th of August and fixed the vulnerability on the 23^rd. In less than two weeks, he had implemented a fix that required changing the endpoint of all API calls. I wish all vendors respected their customers this much. (Amazon, are you listening?)

If you have a public API and want to allow cross-domain Ajax requests with Flash, be sure to use a separate domain. If the user interface and API operate in the same domain, there's almost no limit to what an attacker can do.