Preparing for Flash Player 9 April 2008 Security Update

Adobe has announced security changes and enhancements that will roll out with an upcoming security update to Flash Player 9. The Adobe Developer Connection has an article detailing the changes and who is impacted. If any of the following bullets is applicable to you, please be sure to read the article as your content may be affected.

You use sockets or XMLSockets, regardless of the domain you are connecting to
You use addRequestHeader or URLRequest.requestHeaders in any network API call when sending or loading data cross-domain
You provide access to content on remote domains as a web service provider
You have SWFs that are exported for Flash Player 7 (SWF7) or below that communicate with the hosting HTML by any means
You use “javascript:” through network APIs to communicate outside a SWF

Keep in mind that the descriptions above are meant to capture a broad group of people. The affected areas are tailored to keep normal usage as unaffected as possible. For instance, while the last bullet tries to capture anyone using “Javascript:,” the actual change only involves “Javascript:” being used in ways that I haven’t encountered before. Normal uses through getURL and navigateToURL will be unaffected.

Also, if you are asking yourself, “Didn’t I just hear about socket policies back in December?,” you’d be right. With Flash Player 9.0.115, a two phased approach was announced for authorizing socket policy files. Phase 1 was implemented with 9.0.115, and phase 2 will be rolled out in the April release. By doing a slow rollout of this new authorization process, we wanted to give developers the time they needed to make changes to affected content before their users have a player that enforces the new policies.

While you are in a security frame of mind, I’d like to point out another article that is on the Adobe Developer Connection. Peleus Uhley, senior security researcher at Adobe, wrote an article on development practices for creating secure SWFs that should be required reading for any ActionScript developer.

The Flash Player team works hard to ensure security within the player, but how you design your application is just as important. The flow of data through an application, the configuration of network and script permissions and even where you host your SWF can raise or lower the exposure to your server. Peleus’s article can provide advice that will be valuable to even seasoned ActionScript developers.

18 thoughts on “Preparing for Flash Player 9 April 2008 Security Update”

Justin,

Any other bug fixes to look forward to in this update? Dealing with all the different releases of the Flash 9 plug-in is getting to be problematic.

I recently ran into a show stopper — Mac only — where (Flash, not Flex) AS3 components in a web app worked fine with R115, but were completely broken when testing with older version (R45 and, I think, R47). Happened in both Safari and Firefox.

Reply ↓

Pingback: Developers beware! Upcoming Flash Security Update (April 2008)

http://weblogs.macromedia.com/flashteam/archives/2005/09/its_that_time_a.cfm

Reply ↓

External interface doesn’t work on all browsers and operating systems including some versions of Opera and Linux browsers. To say that we should always “Use external interface” is silly because of that. We use external interface only on browsers that support it. Our clients are going to be royally pissed off if we have to drop support for some browsers/os combinations because of this security update.

Arrgh, we just got over the mess from the last security updates and updated our internal and external docs to take all the .115 changes into account. I wish this could be Beta released prior to being officially released. Too bad it’s security fixes. I know how that works and that nothing, not even potentially creating bugs, holds it off. Additionally, I wish there were some focus placed on fixing the External Interface bugs in IE and other browsers prior to launching this.

Reply ↓

(By the way, the External Interface bug in IE is that it causes JS errors that break External Interface in some cases. We have to workaround this by overwriting Flash’s automatically created functions (such as _addCallback, etc after we create the flash object to add try/catch. Additionally, we have to make sure that our clients always name objects using a certain naming convention, since Flash tries to access the object using NAME.method)

Reply ↓

Thanks for the great tips… I’ve been having trouble with this lately…

Reply ↓

alwx

Reply ↓

good

Reply ↓

Pingback: JD on EP

I’m pretty curious about the secure SWF myself, this would be a great service to those that work so hard to create projects that currently run unsecured. Nice article!

Reply ↓

Pingback: Ryan Stewart - Rich Internet Application Mountaineer » Reminder: Flash Player Security Update in April - Prepare Your SWF