Crossdomain.xml - write access to domain

Question

Is a permissive crossdomain.xml Flash policy analogous to a permissive CORS policy?

i.e. Is

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

the equivalent of

Access-Control-Allow-Origin: <origin request header>
Access-Control-Allow-Credentials: true

e.g. if the attacker site is attacker-site.co.uk over TLS the following headers would be reflected:

Access-Control-Allow-Origin: https://attacker-site.co.uk
Access-Control-Allow-Credentials: true

I would argue that the Flash policy makes things more insecure (from a Flash perspective only) because although they appear to allow the same things, write access is not allowed by Flash unless a permissive cross domain policy file exists, whereas write access to an origin is allowed by default within the Same Origin Policy.

However, since write-access is allowed anyway (non Flash), allowing it in Flash too does not add any integrity risk to the application. Is this correct?

Answer 1

Yes, although the default cross-origin permissions differ between Flash and HTML:

       Write Access (e.g. POSTing data)            Read Access (e.g. req allowing data to be read)

HTML   Allowed                                     Only allowed with CORS
Flash  Not allowed without cross domain policy     Not allowed without cross domain policy

Having said this, it is possible to perform a CSRF attack using Flash without a cross domain policy. Evgeniy Yakovchuk has posted a Github which shows a POC of the issue. This involves the Flash file making a request to a URL on the same origin as the .swf file, however, then the handler for this URL then issues a 307 redirect that causes the request to be sent to the victim site. The crossdomain.xml file is not checked before the request has been redirected, and CSRF is achieved, also with the option of setting a custom content-type header that would bypass the usual browser Same Origin Policy restrictions.

Whether this is "by design" is for Adobe to confirm. They did fix a variation on this that also allowed custom headers to be added which is normally not allowed without a relevant CORS policy, however the 307 redirect issue still remains.

Going back to the table above, since access is allowed by HTML anyway, allowing Flash to "write" to another origin too does not add further risk.

Both methods, as already touched upon, also require additional settings for headers: Flash cannot send custom headers with a request unless the appropriate setting in crossdomain.xml exists:

<allow-http-request-headers-from domain="www.example.com" headers="MyHeader"/>

And any custom headers require a pre-flight request within HTML to ensure the server configuration allows them.

Regarding the integrity risk (within the CIA triad), both could cause an indirect risk if the policy allows anti-CSRF tokens to be read which could then be used to make state-changing requests to the application.