The Dangers of Cross-Domain Ajax with Flash
In a previous blog entry, 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 the 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 websites 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://www.google.com/search?q=inurl%3Acrossdomain.xml
One of the first results was http://flickr.com/crossdomain.xml (it no longer exists - keep reading):
<cross-domain-policy>
<allow-access-from domain="*"/>
</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 easily be the victim in such a scenario.
One of the people involved in the discussion that took place on my blog seemed to have a difficult time grasping the concept, so I doubted my ability to describe the problem. 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 any 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 11 Aug and fixed the vulnerability on 23 Aug. 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.
del.icio.us
Digg
Reddit
Newsvine
18 Comments
1.
Zak Greant said:
2.
James Benson said:
3.
Roderick Divilbiss said:
4.
Ivan said:
5.
Chris Shiflett said:
6.
Chris Shiflett said:
7.
tyler said:
8.
Chris Shiflett said:
9.
Chris Shiflett said:
10.
Chris Shiflett said:
11.
Chris Shiflett said:
12.
strk said:
13.
Renaun Erickson said:
14.
Renaun Erickson said:
15.
Chris Shiflett said:
16.
Chris Shiflett said:
17.
Good Education and Awareness may help said:
18.
Chris Shiflett said: