You deploy the Flex app SWF from some server, but your design may have that SWF getting data from some domain or even sub-domain different from the domain that served the SWF.
So you specify what other domains your SWF can access data from in the crossdomain.xml file. That way if I grab your SWF from a network stream, I can't place it on my server and have it access my malicious data.
That's just one example, but that's tight security.
I don't get it, either. It seems to be a way of limiting your content from being included by a site running on another domain. It's not really about security, from what I can see. See what adobe has to say:
" A cross-domain policy file is an XML document that grants a web client—such as Adobe Flash Player, Adobe Reader, etc.—permission to handle data across multiple domains. When a client hosts content from a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain would need to host a cross-domain policy file that grants access to the source domain, allowing the client to continue with the transaction."
So let's say Company A has some great content and doesn't want it included in Flash apps running on another domain. They put a restrictive crossdomain.xml file in place. I don't know why Company B doesn't just download the content using curl or wget, host it locally, and do the include ... but I guess that comes down to avoiding legal issues.
So this is a content distribution limitation mechanism, not a security feature. Very confusing!
I believe the key scenario works as follows:
You work for a bank. You hook up your computer to the bank's intranet
accessing the bank's servers at http://internal.mybank.com. The bank has
firewalls up preventing servers at evil.com from stealing information from
the internal.mybank.com computers.
A former co-worker sends you an email saying: "Hey, check out my vacation
photos on my facebook page". Using that same computer, you go to his
facebook page. A facebook SWF shows you his vacation photos but is actually
a "secret agent". Unknown to you, it makes a request to internal.mybank.com
because the former co-worker knew that is the URL of the servers.
Because the SWF is running on your computer, it is inside the firewall and
does have access, but Flash won't let the request work because it knows the
secret agent Flash SWF is hosted from facebook.com and there is no
crossdomain.xml allowing it at internal.mybank.com. Otherwise, the secret
agent app would download stuff and redirect it out to evil.com.
^^^ What he said.
Flash is run on the client, which means any website could potentially execute network code behind your firewall. With a desktop application, at least you have to concent to this (IE. downloading and installing it).
does anyone have a good tutorial on how to begin using crossdomain.xml?
i wanted to look into using it but couldnt spend much time figuring out how to add the file to my project. Is it just an empty XML file you create by hand? Or is it generated or added to the project in a special manner? Any help is appreciated....
I would also like to point out that it's common practice to proxy data connections through your own server. The idea is that the crossdomain.xml is placed on your own remote host, and it handles all necessary external communications.
hey Cheers for that, for real, thanks man!
Thanks for sharing that URL. I think this is the section that applies to my XSS issue:
If you imagine that the "public server" is instead a "hacker's server," and that instead of pushing out nice public content he's sharing harmful links to malware, etc., then I think you see the problem
"A public server that allows data access from any domain
Some sites are intended to be accessed by anyone. They contain publicly available data, such as news feeds and web services.
The Flash Player, and web browsers, generally disallow access to data outside the current domain. Because of this, a common practice is to deploy a proxy script on the server that hosts the Flash movie, which then requests data server-side before returning it to the movie.
This is a standard practice, but it requires the creator of the Flash movie create server-side logic just to access public data. If the public server has a policy file, all Flash movies can access its data without any additional server scripts.
A policy file that permits all domains to access it uses a wild card instead of specifying individual domains.
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<allow-access-from domain="*" />