Wednesday, May 14, 2008

Crossdomain.xml Invites Cross-site Mayhem

Update 05.14.2008: Figured I'd make available the list active crossdomain.xml websites I've found. Enjoy! *hat tip to RSnake for the bandwidth*

This week I took a renewed interest in crossdomain.xml. For those unfamiliar this is Flash’s opt-in policy file that extends the same-origin policy to include more sites in the circle of trust. Normally client-side code (JavaScript, Flash, Java, etc.) is limited to reading data only from the website (hostname) in which it was loaded. Attempting to read data from other domains is met with security exceptions.

With crossdomain.xml a site owner may configure a policy to stating which off-domain sites are allowed to read its data (or parts thereof) and the client, Flash in this case, is responsible for enforcement. This feature paves the way for more rich client-side applications. Crossdomain.xml policies are also extremely flexible allowing websites to be defined by IP, domain, subdomain, or everyone (*) under the sun. And this is one area where we potentially run into trouble.

When a hostname is included in the circle of trust you allow them to read all data on the site that the user has access to, this includes any (authenticated) content and (session) cookies. So should a malicious attacker or website owner gain control of a website in the circle of trust (via a server hack or XSS), then they feasibly can compromise user data off that domain. This could easily leads to privacy violations, account takeovers, theft of sensitive data, and bypassing of CSRF protections (grabbing the key ahead of time).

With this understood I was curious just how many prominent websites are actively using crossdomain.xml and generally how they are configured. For sampling I combined the “www” hostnames of fortune 500 with the Global Alexa 500. Of the 961 unique websites in all (and keeping the results to myself for now)…
  • 28% have a crossdomain.xml policy file of some type.
  • 7% have unrestricted crossdomain.xml policy files.
  • 11% have * restricted crossdomain.xml policy files.
I was quite surprised by the penetration, but not as much as how many possessed unrestricted policies. Meaning any website can pull any data from them that they want. It's not just so much that they allow this, many are just brochure-ware so who cares, but others we’re talking very sensitive data here. Then of course domain restricted percentages were higher still. That would mean if a user should get XSS’ed ANYWHERE on the domain (or other *’d domain), easy enough to do, an attacker could load up a flash payload on pilfer the data that way. Ouch. Another thing I noticed was a noticeable amount of intranet (development) hostnames being leaked publicly, weird.

Now if I may take things just one step further because these types attacks can scale far easier and become more damaging that it might first appear. We've already seen several cases where Flash-based advertising is poisoned through an upstream CDN provider eventually leading to the exploitation of users browsers. These attacks are spotted because they take advantage of a well-known vulnerability, load malware detectable by A/V signatures, and detectably compromise a machine. But let's say they didn't do that and instead attempted something subtle.

What an attacker could do is purchase some flash-based advertising delivered anywhere on a domain inside a circle of trust (* Instead of using traditional malware exploits they’d force an innocent looking and invisible cross-domain request on behalf of the user. This request could easily steal session cookies, read your Web email, spam email for that matter, access your social network, and the list goes on and on. Not only would this be inexpensive, but also extremely difficult to detect because everything would appear legit. As I say this, I can’t help but wonder if it hasn’t happened already and we just haven’t realized it. We’re all so used to blaming online account compromises on trojan horse, that we haven’t stopped to consider or investigate other possibilities.

thanks to Russ McRee for blog title and content assistance.


Yousif Yalda said...

Wow, I've heard SOMETHING about this before but I've never got into learning more about it. Thanks for the announcement. Additionally, this sort of works like an RFI expoit right? Choose the content you want to appear to download/view? I mean... does the user only have to compile the .swf to it's original format and simply debug from there? So, lots of domain information is spilled all over, but how it does it look exactly?

Anonymous said...

I came across the "crossdomain.xml" file months ago after I noticed a massive number of requests for it on my own website from an IP I had been serving with a 403 error. I subsequently set this file, which did not exist anyhow, as one of the many that I automatically monitor in order to detect obscure requests. I realized the potential for abuse, but didn't realize how widespread the issue actually was, and never even thought of considering the possible subdomains outlined in the file for accessibility.

I'm slightly confused by your take on the "crossdomain.xml" file, which I'm assuming you are speaking of. The file is not a Flash file, but an XML file which sits on the host in the root directory, and only specifies what third-party websites and domains can access different resources. Flash works in a similar fashion to the DOM in regard to its cross-domain policy in that if an IFRAME element containing "SiteB" is placed on "SiteA" the latter will not be able to access the properties or methods (such as document.cookie) from the IFRAME due to the fact it does not originate from the same origin. For a better understanding of how the file works read Adobe's document on it here ( Also, a Google search for the file will produce a number of results that you can analyze, which may help your understanding.

Yousif Yalda said...

@ awesome andrew - I did not word what I had to say properly, as I already know the crossdomain.xml is uploaded to the host and sets for different domain's content access.

Anonymous said...

Can anyone provide a Google link that will look for crossdomain.xml files with wildcards? Last time I tried it I was blocked from Google for a length of time.

kuza55 said...


It's not quite as bad as you make it out to be; If you'd payed attention to my Bluehat presentation (:p j/k, I realise there were many other things to be doing, though it was in there) the Flash player sets the security context based on the URL from which the Flash file was loaded, and therefore xss will not let you abuse * crossdomain.xml files.

Though thanks for the index, would you consider putting up something interactive so that we could submit crossdomain.xml files so that we could have a huge registry of who trusts what?

Jeremiah Grossman said...

@kuzza55, OMG you only said like 18 billion things that I have to remember! :) I sat there quiet the whole time thinking I know that, and that, and that, hmm... really, didt't know that and that. Nah in all seriousness that was a huge hole in my knowledge. I could have sworn Flash had the same execution domain pattern as JavaScript. Still did you see several of the sites have * and other cdn listed? Eeek.

On the index, maybe we should use a social bookmarking service of some kind. I'll investigate.

Anonymous said...

I find your idea of mapping everyone's trust to be quite interesting, and would agree that it would be awesome to see. I think however that it should be more visual rather than using any social-bookmarking service. I'm envisioning more of an application similar to those which map your network devices, or Music-Map ( Perhaps I'll get on that idea sometime within the next few days.

Jeremiah Grossman said...

Wow, what an interesting concept. Hmph, the data itself is easy enough to gather, its the gui that'll be rough. I wonder if music-map might share their flash with us.

Anonymous said...


I agree with kuza55 that this is not quite as bad as you make it out to be.

1. You mention that some of the crossdomain.xml files you looked at trust Content Delivery Networks like Akamai and that this is scary. I can see a lot of cases where a Flash SWF file would be served up by a CDN for performance reasons, but the SWF would need to make an HTTP request back to the origin website to grab some data that it needs to use/display. What's so bad about this?

2. Also, often a website will have an open crossdomain.xml policy, but the hostname that has this open policy doesn't host any senstitive content/functionality. So just the fact that a website has a "*" in their crossdomain.xml policy isn't necessarily a big security hole, it depends on the context. A lot of the big Fortune 500 companies on your list use their main hostnames to serve up essentially static content and host their sensitive web applications on separate subdomains.

3. You mention that if a site has an open crossdomain.xml policy, it's possible for any other site to host an Flash SWF file that steals session cookies from the site with the open policy. How would this be done? I can see using the SWF file to conduct a CSRF attack against the site (you can trigger GET and POST requests from within Flash), but how would you read the users' session cookies?

Jeremiah Grossman said...

@Brian, one things for certain, I had my domain contexts confused as pointed out by Kuza55. Now to your comments.

1) The scary/risky thing is the flash content is not always controlled by the website owner and may can contain malware (ads). The same is true of JS of course. So whatever the flash has access to, so does the bad guy.

2) Agreed. The risk is dependent on the content obtainable or the current state of the users browser the bad guy would be in control of. Its the penetration of the the crossdomain.xml file I was looking at and I only checked the main pages of those companies. I could extend out the search to see what is actually out there. I'd have to write more robust code.

3) That was my error corrected by kuza55. The only way to go about it would likely auto XSSing a user, not necessarily hard, just another step.

Anonymous said...

Hi Jeremiah, I've actually been planning on blogging on this subject for a while, so this post was timely.

I put together a quick primer on the various cross-domain loading & scripting mechanisms available in Flash here:

Hopefully it will serve as a useful starting point on the subject.

Mikael Bergkvist said...

Is this really an issue, or is it similar to this 'homeland security buggalooo terrorists are going to kill us all" bullshit paranoia?
I'd like better explanation of the various exploitation scenarios.

Jeremiah Grossman said...

I decided to stop short of building that particular piece of PoC. In all seriousness, I'll likely build some example as suggested to make it more real

Anonymous said...

I'm not quite sold on how CDN's with * in their cross-domain files is an issue. It would only be an issue if the CDN implements authenticated browser sessions, which would seem like a big problem in and of itself.

At the risk of simplifying, cross-domain policy files with * in them can be a problem when:
a) the server hosting them is behind a firewall (i.e. intranet)
b) the server hosting them relies on authenticated browser sessions

If you are hosting untrustworthy ads, or other 3rd party content, you have much bigger issues than crossdomain.xml IMHO.

Jeremiah Grossman said...

Hi Lucas, clearly I had the execution model backwards from my previous comment, and your spot on with the CDNs serving malware as being a much larger problem. However, let me run this by you and see if it passes the smell test...

Take the crossdomain.xml file of (trusts *, (trusted *, and (trusts * as examples. I think its safe to assume that it would be easy to get flash ads to appear on those CDN domains which get then delivered by the websites listed. In this instance very subtle and hard to detect flash malware could then access whatever the user could on those pages. Correct?

Now if this is found to be a problem, the next question is how far and wide this type of trust model exists.

Anonymous said...

Hi Jeremiah,

I certainly would not recommend that sites with browser managed sessions blindly trust entire CDN's or ad networks.

It depends on the particular CDN's architecture, but generally the best practice I seen is to trust only the explicit CDN subdomain assigned to a given client.

As for advertising, the best practice is to not trust advertising networks at all (trust being defined as this case as granting access via crossdomain.xml, allowScriptAccess, old fashioned JSON, etc.) Unfortunately the ad serving models are so complex & convoluted that they often force the hosting website to trust the ad servers, with predictably unfortunate results (as O'Reilly discovered recently:

I'm not trying to discount the risks of misconfigured crossdomain.xml files, but some of these issues unfortunately extend beyond just policy files.

Speaking of best practices, there is also a write-up of crossdomain.xml security located here:

Jeremiah Grossman said...

Couldn't disagree with a single word. Obviously the browser security model needs some additional features and granularity involved. Thanks for the references!

Unknown said...

I don't see what the crossdomain.xml with *.* would give the swf file that you couldn't just get to by typing in the URL on the server in a browser.

Anonymous said...

step one: user connect to secure(but not https) server and now has access to there restricted content i.e. a profile page with their SSN, address DOB, etc.
step two: user visits unrelated site that is serving ads from a common ad network.
The initial site has a crossdomain.xml allowing access from this *trustworthy* ad provider.
step three: a malicious agent sets up an account with said ad provider and submits an innocious swf based ad.
step four: it all comes together, Ad network serves naughty flash to user, flash makes call to secure web site for the profile page. Flash security checks crossdomain.xml to see if this is allowed (and it is). flash scrapes data and posts it to another site for mischief later.

Anonymous said...

hello there. I have found your website while browsing the web and i hope you can help me.
my website is live since one year. recently, everynow and then, let's say once every 50 visitors i get a visitor coming from a google search who visits my website. he visits a page of my blog and along with it a page which my blog doesnt have such as

what is it? is it an hacker attack, or it is an error coming from my wordpress theme? can you reply please? thanks

Anonymous said...

thank u r information

it very useful

u r blog Is very nice

Anonymous said...

Zattoo's crossdomain.xml:

aaron said...

crossdomain.xml cannot be used to steal cookies! It does not allow any additional access to cookies through javascript. It allows Flash to access XML, JPG, PNG, or SWF resources on a remote domain. It has no relationship to javascript cross-domain security except a superficial resemblance. Flash also has a method for retrieving cookies, but it has no connection to the crossdomain.xml. Flash can only read cookies from its own domain.

There are some subtle security considerations with crossdomain.xml, but nothing close to what you describe. See this article from Adobe for more info.

Can you post a link to any example that can show a Flash movie at domain A and a crossdomain.xml file at domain B where the malicious SWF at domain A is able to steal a cookie from domain B thanks to the crossdomain.xml on domain B? If so, I will quit my career as a Flash developer. If not, and you cannot find nor create such an example, I request that you retract or correct this article.

Anonymous said...

Nice post author. However I don't think you know what you are talking about. Cross domain is not going to allow other users from hi-jacking another users's security cookie. If that is possible, then adobe would be sued a million times by now.

Cross domain is only used to set security in the access in between server and swf files. How you manage sessions, cookies, internal data are all dependent on the server's configuration.

For example, if I have a servlet running on port 100, and it will spit out say a list of names from the database, having a cross domain file set to the servlet's own URL means that, only SWF files hosted on the servlet's URL can access this servlet through as3 URL connection. However, the servlet is still public to hackers.
A simple POST plugin in Firefox can easily open the servlet and retrieve the same information because FIREFOX is not internally guarded by the cross domain file.

Long story short, cross domain has nothing to do with how the back end is managed.