About the Author

Chris Shiflett

Hi, I'm Chris, a web developer and a founding member of Analog. I live and work in Brooklyn, NY.


The Dangers of Cross-Domain Ajax with Flash

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.)

<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 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 11th of August and fixed the vulnerability on the 23rd. 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.

About This Post

The Dangers of Cross-Domain Ajax with Flash was posted on Sun, 24 Sep 2006 at 18:19:04 GMT.

19 Comments

1. Zak Greant's GravatarZak Greant said:

Hey Chris,

[announcement type="public service"]

This (among other things) is one of the reasons that we really need a Free Software/Open Source Flash player.

Thankfully, Rob Savoye and crew are working on Gnash, a Free Software Flash player that includes a security manager.

Visit http://www.gnu.org/software/gnash/ to learn more.

You might want to chat with Rob a bit to learn more about the security implications of Flash movies - drop me a line and I will pass on his email address.

[/announcement]

Cheers!

--zak

Sun, 24 Sep 2006 at 19:16:39 GMT Link


2. James Benson's GravatarJames Benson said:

Very interesting stuff!

Mon, 25 Sep 2006 at 18:58:00 GMT Link


3. Roderick Divilbiss's GravatarRoderick Divilbiss said:

Such a simple, yet potentially damaging vector. I am dismayed that so few people have bothered to Digg this.

Mon, 25 Sep 2006 at 23:52:09 GMT Link


4. Ivan's GravatarIvan said:

Sadly, if Chris wanted attention, he should have disclosed this information before Flickr had a chance to fix the problem.

I'm glad he chose to wait.

Tue, 26 Sep 2006 at 01:04:57 GMT Link


5. Chris Shiflett's GravatarChris Shiflett said:

Julien has now written about this:

http://blog.monstuff.com/archives/000302.html

Tue, 26 Sep 2006 at 01:07:12 GMT Link


7. tyler's Gravatartyler said:

I'm not sure you are right about this. the cross-domain file alows flash to read files from remote servers, this has nothing to do with writing files or making calls to that domain. You us a cross-domain file in a web service so that flash can read it's xml files. I'm not sure about how "there is no limit to what an attacker can do". I could be wrong about this but I wont disagree that it is a good thing to separate your webservices domain from your public site.

Thu, 28 Sep 2006 at 14:41:58 GMT Link


8. Chris Shiflett's GravatarChris Shiflett said:

I'm sure I'm right about this. The exploit worked. That's an objective observation.

Thu, 28 Sep 2006 at 17:45:02 GMT Link


9. Chris Shiflett's GravatarChris Shiflett said:

YouTube is vulnerable:

http://youtube.com/crossdomain.xml

Fri, 29 Sep 2006 at 23:24:21 GMT Link


10. Chris Shiflett's GravatarChris Shiflett said:

YouTube has been notified.

Fri, 29 Sep 2006 at 23:34:25 GMT Link


11. Chris Shiflett's GravatarChris Shiflett said:

MusicBrainz is also vulnerable:

http://musicbrainz.org/crossdomain.xml

They have been notified.

Fri, 29 Sep 2006 at 23:37:57 GMT Link


12. strk's Gravatarstrk said:

could you explain to me again what is possible that is not with normal HTTP, when you use a crossdomain.xml allowing full access from anywhere ?

I seem unable to grasp the concept, and the whole 'crossdomain.xml' thing seems only based on control

over the player, which can only be assumed by making user NO OTHER PLAYER then the uncorrupted MM one exists.

Mon, 20 Nov 2006 at 15:46:52 GMT Link


13. Renaun Erickson's GravatarRenaun Erickson said:

This does not stop security issues you can do the same things with HTTP api calls. The security lies in the API and the trust apps them selves. These large services if they want to, can open up API's for people to make mashups.

Shutting down the crossdomain.xml doesn't change the "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."

You could do the same thing with a scripting language based app that would do the same thing. These are open API's by Flickr so people can build apps on top of their service.

Wed, 13 Dec 2006 at 19:09:20 GMT Link


14. Renaun Erickson's GravatarRenaun Erickson said:

I think I was still confused with my first statement. I am trying to put it all together. It finally hit me that I was meshing the API and the normal main site token authentication together.

"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."

That helped clear it up.

Wed, 13 Dec 2006 at 21:50:33 GMT Link


15. Chris Shiflett's GravatarChris Shiflett said:

Renaun, hope it makes sense now. :-)

Thu, 14 Dec 2006 at 21:47:42 GMT Link


16. Chris Shiflett's GravatarChris Shiflett said:

YouTube is no longer vulnerable.

Thu, 14 Dec 2006 at 21:48:20 GMT Link


17. Good Education and Awareness may help's GravatarGood Education and Awareness may help said:

Note sure if this is already obvious to everyone, but it seems that "PowerSDK Software Corp." has registered the domain "http://www.crossdomainxml.org/". I sure hope that Yahoo and Flickr (Google too?) will keep their sites open for external developers. Cross domain access is truely useful when the "big sites" opt in. I just hope we don't lose it. Will it be possible for crossdomainxml.org to be kept up to date with policy file location information and status?

Sat, 30 Dec 2006 at 14:32:01 GMT Link


18. Chris Shiflett's GravatarChris Shiflett said:

YouTube has an open policy again, isolated to a subdomain like Flickr:

http://gdata.youtube.com/crossdomain.xml

Wed, 27 Feb 2008 at 22:21:08 GMT Link


19. Kyle Simpson's GravatarKyle Simpson said:

I've got a project called 'flXHR' http://flxhr.flensed.com/ which is a flash+javascript direct re-implementation of the native XHR api, but using an invisible flash object to allow cross-domain requests. Since it's API is identical, it's an easy drop-in replacement for native XHR, and can thus be used very easily with any existing code or JS frameworks (like jQuery, Dojo, etc).

Since it uses flash (specificaly 9.0.124+), it utilizes the newest, strongest implementation of Adobe's cross domain server opt-in policy to authorize such communication, which makes the communication using flXHR inherently more secure, more efficient, and less hacky than many of the other common cross-domain workarounds available right now.

In addition, by centering on the native XHR API, flXHR becomes an effective "future-proof" drop-in solution until such time as browsers extend those API's to allow for native cross-domain-safe communication.

Mon, 20 Apr 2009 at 14:14:41 GMT Link


Post A Comment

Personal Details and Comment

Style Guide

Line breaks are converted to paragraphs. Also use:

  • <a href="" title="">text</a>1
  • <em>text</em>
  • <blockquote><p>text</p></blockquote>
  • <code>2  <?php  if ($foo) {      $foo = TRUE;  }  ?></code>
  1. Note: <code> can be used inline (e.g. in paragraphs) or in a block as shown. Include whitespace and newlines in blocks.

Please enter Chris (my first name) below. This is a primitive spam prevention technique, and I apologize for the inconvenience.

Preview and Submit

Upcoming Talks

ConFoo

10 - 12 Mar 2010

At Hilton Montréal Bonaventure, Montréal, Canada.

South by Southwest

12 - 16 Mar 2010

At Austin Convention Center, Austin, Texas.

Dutch PHP Conference

10 - 12 Jun 2010

At TBD, Amsterdam, Netherlands.

O'Reilly Open Source Convention

19 - 23 Jul 2010

At Oregon Convention Center, Portland, Oregon.

New Comments

Niall Kelly wrote:

Having tried other methods without success and looked through plenty of bloated documentation, th...

Posted in Git on Snow Leopard
liukang wrote:

I have problem with this example. In my php.ini magic_quotes_gpc is off so i'm using only addsla...

Posted in addslashes() Versus mysql_real_escape_string()
RyanTheGreat wrote:

Well, I'm not Chris, but I will do my best to address the questions raised in the comments by Ian...

Posted in Security Corner: Cross-Site Request Forgeries
Chris Shiflett wrote:

Thanks for the kind words, Simon. I'm glad you liked the tutorial. In case it's helpful, here'...

Posted in Webstock
Chris Shiflett wrote:

Hi Robin, I plan to post something about it, but it's going to be hard to express everything i...

Posted in Webstock

Browse Comments


Work and Books

Analog Essential PHP Security HTTP Developer's Handbook