new and exciting security policy settings in flash moviestar

In addition to all new video capabilities, the recent 9.0.115 release of the Flash Player contains an update to the security policy framework that I haven’t seen much press about. I guess the nickname crossdomain smackdown just wasn’t sexy enough compared to moviestar.

I discovered the new framework by accident when the following message showed up in my Flash debugger log files

Warning: Domain marstonstudio.com does not specify a meta-policy.  Applying default meta-policy 'all'.  This configuration is deprecated.  See http://www.adobe.com/go/strict_policy_files to fix this problem.

Intrigued, I followed up and wound up reading this excellent, thorough, and long article about the new crossdomain file options. In short, Adobe is addressing vulnerabilities that have become apparent with the original crossdomain policy approach. For people in a hurry, here are the highlights.

My old crossdomain.xml file looked like this

<?xml version="1.0" encoding="UTF-8"?>
<DOCTYPE cross-domain-policy SYSTEM "http://adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*.marstonstudio.com" />
</cross-domain-policy>

My new crossdomain.xml file looks like this

<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
    <allow-access-from domain="*.marstonstudio.com" />
    <site-control permitted-cross-domain-policies="master-only"/>
</cross-domain-policy>

The interesting changes are the use of a schema instead of a DTD, and the new site-control element. My choice of the value master-only means that the only acceptable file name and location for a crossdomain file is the default crossdomain.xml at the site root. There are some other options for this value that permit flexibility, but I’m keeping it simple.

The other change is to my mm.cfg file that controls the Flash Debugger Player logging behavior. There are two new configuration options and a new log file. The new settings are

PolicyFileLog=1     # Enables policy file logging
PolicyFileLogAppend=1   # Optional; do not clear log at startup

These settings control the logging to the new policyfiles.txt log file, which should appear in the same directory as your flashlog.txt file.

That’s the Cliffs Notes version that will help out most people. Read the full Adobe article by Deneb Meketa to learn about socket policies on port 843 along with other new and exciting security policy settings.

Creative Commons License
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

11 comments ↓

#1 John Dowdell on 12.07.07 at 12:44 am

Thanks for catching this; I’ve been wanting to draw attention to it too.

Best thing right now is, if you’ve ever used cross-domain policy files, to test those existing projects with the new Player. If it works, great. If it doesn’t, check for well-formedness of the policy file itself (via those schema), and check against redirects within the domain.

Then, when you get the chance, check the logs on the debug Player against those sites. This will flag practices which the current Player will accept, but the next Player will likely not.

Deneb’s article has full details. Thanks again for drawing attention to this change!

jd/adobe

#2 julien on 12.07.07 at 2:15 am

Very useful thanks for the info

#3 Untitled :: Blog Archive » new flash security policies on 12.13.07 at 6:14 pm

[...] the bit where they improved the format for crossdomain.xml files doesn’t really affect me one way or the other. I approve of the improvements but could really [...]

#4 Sherif on 12.17.07 at 7:22 am

I’m having issues with the new security changes. I connect to an XMLSocket on port 17000, and the crossdomain.xml file was served from the web root of that server. Obviously this isn’t working anymore.
From what i understand, to solve this I need to serve the file on port 843 or respond to the “.” with the xml file. Is that right?

Adobe haven’t given enough notice on this and also not providing much help to Flash developers to resolve their issues.

Thanks

#5 Sherif on 12.17.07 at 7:41 am

From what i understand, to solve this I need to serve the file on port 843 or respond to the [policy-file-request] with the xml file. Is that right?

#6 Subash Chandra Bose on 12.27.07 at 12:40 pm

Thanks for the easy tutorial on cross domain security issue…

Based on the tutorial I have modified my crossdomain.xml to

<allow-access-from domain=”*.mydomain.com” />
<site-control permitted-cross-domain-policies=”master-only”/>

The mail server application works fine when i connect to mail server through
port 1030 & 1031 when i run the swf and html inside eclipse plugin.

But when i run the same through browser
http://localhost:8600/testdrive/gft/bin/WebMail.html

I get the following error.

[SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048"]

What can be the issue. where i am wrong???

#7 jon on 12.27.07 at 12:52 pm

Subash: I think the problem is that your crossdomain policy only allows connections from subdomains of mydomain.com, which excludes the domain ‘localhost’. One way to get around this problem is to open your crossdomain to everyone in the world by adding a node to your policy of allow-access-from domain=”*”. However, this defeats all the good security benefits of having a crossdomain policy. Instead, I would add an alias in your /etc/hosts file:
127.0.0.1 local.mydomain.com
Then to access the application within eclipse, use the address:
http://local.mydomain.com:8600/testdrive/gft/bin/WebMail.html

#8 Be careful with the new Flash Player 9.0.115.0 security changes. at code zen on 01.13.08 at 9:43 pm

[...] can be found here on the Adobe Devnet site. A more bite sized sum-up of the article can be found here. As you see, the 2 big changes is the move to XML schemas rather than DTDs and a new site-control [...]

#9 netdragon on 03.07.08 at 7:01 pm

Also, make sure the server returns a response header with “Content-type: text/xml” for crossdomain.xml. Failure to return a Content-Type response header or returning a non-xml content type will cause Flash to ignore the call.

#10 Billigflüge on 09.09.08 at 10:13 am

thanks for the blogpost, since it is very useful, and special thanks to #1 John, thank you for the hint.

#11 Ted on 02.12.09 at 1:02 pm

When you say “new and exciting” I presume you mean “pain in the arse” or maybe “how Adobe stopped multiplayer Flash development in its tracks” – Multiplayer Flash games are now impossible to develop without root access to your own server. It’s unlikely Flash will ever grow beyond ‘advertising fluff’, as the majority of good developers dont have (or want) that level of access and so can’t do anything remotely sophisticated.

Leave a Comment