Comment by simonw | Hacker News Reader

Comment by simonw | Hacker News Reader

Parent Full thread

A good reminder to audit your crossdomain.xml files, and make sure everyone who might edit them understands the security implications of doing so. I've seen this exact issue affect a whole bunch of very large services - it's an incredibly common mistake.

n.b. the space after asterisks are to avoid italics

http://services.digg.com/crossdomain.xml

<allow-access-from domain="* "/>

http://api.search.live.net/crossdomain.xml

<allow-http-request-headers-from domain="* " headers="* "/>

<allow-access-from domain="* "/>

http://webservices.amazon.com/crossdomain.xml

<allow-access-from domain="* "/>

http://s.ytimg.com/crossdomain.xml

<allow-access-from domain="* "/>

http://profile.ak.facebook.com/crossdomain.xml

<allow-access-from domain="* "/>

<site-control permitted-cross-domain-policies="master-only"/>

http://www.vimeo.com/crossdomain.xml

<allow-access-from domain="* "/>

https://api.ebay.com/crossdomain.xml

<allow-access-from domain="* "/>

Just having <allow-access-from domain="* "/> in your crossdomain.xml doesn't mean you have a security issue.

In case of an API, it makes perfect sense to allow crossdomain flash access. After all, this is what an API is made for, allowing access for third party services.

It is only problematic if you don't have proper authentication, e.g. when a flash app can use the cookie of the user to authenticate.

If the domain is the same one that the rest of your site runs on, it almost certainly does mean you have a security issue. The only practical way to protect against CSRF attacks is to use a secret token in a hidden form field to authenticate all form submissions. allow-access-from-domain="*" means that an attacker can steal your CSRF tokens using a hidden Flash applet running on their malicious page, then use that token to construct a CSRF attack form submission. That means they can perform any action on your site as if they were the targeted user. That's bad.

If you want to provide access to an API, put the API on a separate subdomain. That's why api.flickr.com has an open crossdomain.xml file and flickr.com doesn't.

Adobe actually have a pretty good explanation of the security issues caused by an open crossdomain.xml file:

http://www.adobe.com/devnet/flashplayer/articles/cross_domai...

If you want to provide access to an API, put the API on a separate subdomain. That's why api.flickr.com has an open crossdomain.xml file and flickr.com doesn't.

That's what I was referring to. OP listed domains which are probably used exclusively to provide an API, e.g. api.ebay.com, implying that the crossdomain files on these domains pose a security risk.

I was wondering if my comment is understandable, obviously it's not :) Thanks for the clarification!

And you are right, a * is not a exploit but the starting point of looking for one. You still need to get content on the domain somewhere and ppl to read it, I was taking that as a given from the description of the problem which states that explicitly.

tbh I just did a google for crossdomain ext:xml and pulled out the famous domains with * in the policy.

Reply on news.ycombinator.com