10 June 2010
Note: The following article is for developers only. Customers who are experiencing Adobe Flash Player installation issues should begin troubleshooting in the Flash Player Support Center.
Adobe Flash Player 10.1 and Adobe AIR 2 offer a variety of new features and enhancements, as well as some changes to previous behavior. A few of these changes may occasionally require existing content to be updated to comply with stricter security rules. Other changes introduce new abilities that were previously unavailable or restricted by security rules.
Please review the following security-related changes made in Flash Player 10.1 and AIR 2. Use this list to determine whether you will need to make changes to your existing content for it to function correctly in this Flash Runtime release.
This section describes changes that may require you to update existing content. Adobe takes great care to minimize disruption to existing content, and we believe that all of the issues mentioned here should impact only a very small fraction of existing content.
In some cases, after loading a SWF, image, or sound file, ActionScript may not be able to see the full URL of the loaded file.
This restriction affects the ActionScript 3 properties
Sound.url, and the ActionScript 1 / ActionScript 2 property
MovieClip._url. When the full URL is not visible, these properties will reveal only the domain portion of the URL; for example, http://www.example.com/path/my.swf will be truncated to http://www.example.com/. ActionScript 3 code can detect truncation by referring to new Boolean properties called
Sound.isURLInaccessible. There is no API to indicate truncation in AS1/AS2.
URLs are truncated only when three conditions all occur: an HTTP redirect occurs while loading the file, the file is from a different domain than the caller, and the caller does not have permission to access the loaded file.
Permission to access the loaded file—and thus its full URL—depends on the file's type and uses existing permission mechanisms. Permission to access SWF files is granted when the loaded SWF file calls
Security.allowDomain (ActionScript 3) or
System.security.allowDomain (ActionScript 1 / ActionScript 2). Permission to access image and sound files is granted when the file's server contains a policy file permitting access. ActionScript 3 callers that need to access full image or sound URLs should ensure that policy files are preloaded by setting
This change can potentially affect any SWF file that refers to the
MovieClip._url properties. This change affects all SWF files of all versions that are played in Flash Player 10.1 or later. This change affects all non-app content in Adobe AIR 2 or later (however, AIR app content is unaffected).
Developers should test their content using Flash Player 10.1. If there are adverse effects from URL truncation, developers will need to either update their SWF content to be able to function with truncated URLs or obtain permission to access the files they load, using the
allowDomain or policy file mechanisms described above.
In Flash Player, a SWF file may only clear the system Clipboard in response to a user-initiated action (mouse click, keyboard input, etc). This restriction affects the ActionScript 3 methods
This change reflects the fact that clearing the Clipboard is a form of writing to the Clipboard. Writing to the Clipboard has required UIA for several releases, as described in this developer article.
This change can potentially affect any SWF file that calls the
Clipboard.generalClipboard.clearData() methods. This change affects all SWF files of all versions that are played in Flash Player 10.1 or later. This change affects all non-app content in Adobe AIR 2 or later (however, AIR app content is unaffected).
Developers should test their content using Flash Player 10.1. If there are adverse effects from UIA requirements, developers will need to update their content to clear the Clipboard only in response to user input events.
When ActionScript 3 code uses a for-in or for-each loop to iterate through the properties of an Object, the order in which properties are visited may occasionally differ from previous Flash Player versions.
Consider two different categories of Object property names: simple and complex. For the most part, simple property names are integers and complex property names are strings. However, it is possible to use any value as a property name—so, for completeness, Boolean, null, and undefined values are simple property names; all other types, including objects and non-integer numbers, are complex property names. Here is an example:
var obj : Object = new Object(); obj = "a"; // simple property name (integer) obj["one"] = "b"; // complex property name (String) obj.two = "c"; // complex property name (String)
The for-in and for-each ordering will change only in cases where an Object has both types of properties—simple and complex. The Object in the example above has both types, so its for-in and for-each ordering may change in this Flash Player release. The specific change is that all simple property names will be visited first, followed by all complex property names.
It is documented in the ActionScript 3 language reference that the order of for-in and for-each iteration is not defined, so hopefully most ActionScript 3 code does not depend on the order of iteration remaining unchanged.
This change can potentially affect any ActionScript 3 SWF file that uses a for-in or for-each loop. This change affects all SWF files of all versions that are played in Flash Player 10.1 or later. This change affects all content (both app content and non-app content) in Adobe AIR 2 or later.
Developers should test their content using Flash Player 10.1 or AIR 2. If there are adverse effects from for-in or for-each iteration order, developers will need to update their content to operate independently of iteration order.
This section describes new functionality. No action is necessary unless you want to take advantage of this new functionality.
In the Flash Player ActionScript 3 API, the methods for loading SWF files are the same as the methods for loading image files (JPEG, PNG, and GIF). Occasionally it may be desirable to load an image and ensure that it is not possible for a SWF file to be loaded instead. One situation in which this is especially important is sandbox importing: loading an image file from another, potentially untrusted domain and reassigning it into the loader's security domain. Importing an untrusted image file is generally harmless, since the supported image file formats cannot contain executable code, while importing an untrusted SWF file is considerably more dangerous.
There are two Flash Player methods that perform sandbox importing. Both are available in ActionScript 3 only. The first is
Loader.loadBytes, which takes raw binary data from ActionScript and loads it as display media. The second is
LoaderContext.securityDomain = SecurityDomain.currentDomain, which loads media from a URL.
As of Flash Player 10.1 and AIR 2, you can restrict both of these methods to load only images by specifying
LoaderContext.allowCodeImport = false. Here is some sample code using
var ld : Loader = new Loader(); ld.contentLoaderInfo.addEventListener("complete", onLoadComplete); ld.contentLoaderInfo.addEventListener("securityError", onSecurityError); var lc : LoaderContext = new LoaderContext(); lc.allowCodeImport = false; ld.loadBytes(myByteArray, lc);
If the content to be loaded is a SWF file when you have set
LoaderContext.allowCodeImport = false for an import operation, a
SecurityError event will be dispatched, indicating error 3226:
"Cannot import a SWF file when LoaderContext.allowCodeImport is false."
LoaderContext.allowCodeImport affects only cases that perform sandbox importing—so, for example, an ordinary
Loader.load operation will always load either a SWF file or an image file, even if
LoaderContext.allowCodeImport = false.
LoaderContext.allowCodeImport is a generalization of an earlier, AIR-only property, called
LoaderContext.allowLoadBytesCodeExecution. In AIR, the two properties are now synonyms. In AIR, the
LoaderContext.securityDomain property is unsupported, so the only method that performs sandbox importing in AIR is
Loader.loadBytes, which is why the older AIR-only property was called
allowLoadBytesCodeExecution. The new property name,
LoaderContext.allowCodeImport, is preferred because it is also supported in Flash Player.
There are two common reasons why a SWF file would import an image file into its own sandbox. The first is that
Loader.loadBytes allows dynamic image processing and replication. The second is that importing removes security restrictions, such as for inspecting pixel values or calling
Note: Importing an image in the first place always requires a policy file—so this is just a means of moving a security check up to an earlier stage.
To stay informed of the latest developments in Flash Player security, visit the Security Topic Center. Adobe publishes an article like this one for every Flash Player release.
You should also download Flash Player 10.1 from the Flash Player Download Center.