What does this crossdomain.xml imply?

Question

When a site has the following crossdomain.xml configurations. What does the following imply?

Second, if Site A (http) hosts a flash uploader script which uploads to S3, is this crossdomain.xml file safe to have on the S3 root dir?

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <!-- 
    Read this: www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html 
  -->

  <!-- Most restrictive policy:
  <site-control permitted-cross-domain-policies="none"/>
  -->

  <!-- Least restrictive policy: -->
  <site-control permitted-cross-domain-policies="all"/>
  <allow-access-from domain="*" to-ports="*" secure="false"/>
  <allow-http-request-headers-from domain="*" headers="*" secure="false"/>

  <!--
    If you host a crossdomain.xml file with allow-access-from domain="*"    
    and don’t understand all of the points described here, you probably     
    have a nasty security vulnerability. ~ simon willison
  -->
</cross-domain-policy>

Answer 1

This is the most permissive variation, probably given by the host, not the site owner. This is because of permitted-cross-domain-policies node, if it was your own site, where you aren't hosting other people's sites, you'd like to restrict the rules to only this one file.

The allow-access-from allows content loaded from HTTPS to make calls to this domain via HTTP and vice versa. This is something that in your own site you would probably not allow, but who knows, sometimes advertisements need to do it. I don't think that to-ports attribute in this context has any effect as this file will be only accessed via HTTP(S), which, normally, on public servers listen on port 80/443.

The allow-http-request-headers-from seems redundant, but I'm not sure, the policies changed a lot in the past... I don't know of any headers that have been restricted by default, but possible to send from Flash otherwise. You will find more severe limitations on client side, if any.

Re' your other question, well, obviously, I'd restrict it to only the site A, not all sites. I'd also declare this crossdomain a master (instead of allowing child crossdomains). I would probably remove the allow-http-request-headers-from entirely, as well as to-ports attributes. If you believe that you may have situation when your SWF is loaded through HTTPS, but will try to upload using HTTP, then leave secure attribute as is, otherwise either remove it, or set to true.

More than that... Well, this is a "bonus". After much of intercourse with Flash HTTP I've come to conclusion that if you have the time and necessary facilities, such as you can add server modules, for example, or you may affect the way your server functions. E.g. there is an Apache module that lets it serve the socket crossdomain policy. It's better to implement the part of HTTP that you need using Socket class instead of using half-a*ed Adobe's implementation.

The whole crossdomain business might give you some false feeling of security, while it is actually security by obscurity. Because of it being extremely inconvenient, coupled with Flash own lacking implementation of HTTP you would run yourself into a place, where you are forced to do much worse things than reinventing HTTP :). You'll remember about that once you will need response headers for example... ;)