

Massive Facebook and MySpace Flash Vulnerability Exposes User Data - ed
http://www.techcrunch.com/2009/11/05/massive-facebook-and-myspace-flash-vulnerability-exposes-user-data/

======
simonw
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.

~~~
wendroid
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="* "/>

~~~
danielh
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.

~~~
simonw
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...](http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html)

~~~
danielh
_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!

~~~
wendroid
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.

------
jacquesm
The researcher is called Yvo Schaap (not Schapp!), a dutch guy, here is the
original article:

[http://www.yvoschaap.com/index.php/weblog/facebook_myspace_a...](http://www.yvoschaap.com/index.php/weblog/facebook_myspace_accounts_hijacked/)

------
pbhjpbhj
<http://kb2.adobe.com/cps/142/tn_14213.html> gives background info on what the
crossdomain.xml file is for, for those like me who hadn't come across it
before.

Wouldn't you use htaccess rules (or similar) to prevent the .xml file from
being accessed except from domains who were to be allowed flash crossdomain
access, belt and braces as it were?? Certainly you'd put it as a deny in
robots.txt, no?

------
CapitalistCartr
" . . . steal all of your account data, including your photos, personal
messages, and basically everything else you’ve ever put on the social
networks, without you ever realizing it."

Its Facebook! Everything you put on a site like that is public, or can be and
will be at some point. Its a public forum, as this one is, and any promises to
the contrary have been clearly proven false on about a weekly basis.

------
cl3m
He originally posted on reddit :
[http://www.reddit.com/r/programming/comments/a11mv/facebook_...](http://www.reddit.com/r/programming/comments/a11mv/facebook_and_myspace_security_backdoor_wide_open/)

------
joubert
What I find truly amazing is that I don't see it covered by the big news
providers yet. Not on NYT, not on CNN, not on Reuters, not on NPR.

~~~
maukdaddy
One of those is not like the others.

------
stuff4ben
it doesn't sound like this is a Flash vulnerability per se, but rather a
misconfiguration of Flash on Facebook's and MySpace's websites right?

------
pasbesoin
The techcrunch article links to this brief article, that I find both chilling
and enraging.

[http://code.google.com/p/doctype/wiki/ArticleFlashSecurityPo...](http://code.google.com/p/doctype/wiki/ArticleFlashSecurityPolicyAttack)

 _System.security.loadPolicyFile() is an ActionScript function in a Flash
application that loads any URL, of any MIME type, and attempts to read the
security policy in the HTTP response. If an attacker could upload and store an
image, audio, RSS feed, or other file on a server that can later be retrieved,
then he or she could place the Flash security policy in that file. For
example, the following RSS feed is accepted as an open security policy...

Even worse, the file does not even have to be XML. The GIF image below places
the Flash security policy in a GIF comment and is also accepted as an open
security policy...

In fact, an attacker can embed the security policy within the data of any
valid image, audio or other data file. This is easier to do so with
uncompressed file formats, like BMP image files, but is possible in virtually
any file format. The only limitations are that each byte before the </cross-
domain-policy> tag must:

    
    
        + Be non-zero,
        + Have no unclosed XML tags (no stray <, 0x3c), and
        + Be 7-bit ASCII (bytes 0x01 to 0x7F)
    

_ [YC admins: My trailing "emphasis" asterisk was remaining visible until I
placed (this) further text following it.]

