by Deneb Meketa

Deneb Meketa
Deneb Meketa

Created

10 June 2010

Requirements     

               
User level
Intermediate
 
 
 
 
 
 
   
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.
 

 
Changes that may require action

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.
 
 
Redirected URL truncation
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 LoaderInfo.url and 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 LoaderInfo.isURLInaccessible and 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 LoaderContext.checkPolicyFile or SoundLoaderContext.checkPolicyFile to true.
 
 
What is impacted?
This change can potentially affect any SWF file that refers to the LoaderInfo.url, Sound.url, or 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).
 
 
What do I need to do?
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.
 
 
UIA for clipboard clearing
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 Clipboard.generalClipboard.clear() and Clipboard.generalClipboard.clearData().
 
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.
 
 
What is impacted?
This change can potentially affect any SWF file that calls the Clipboard.generalClipboard.clear() or 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).
 
 
What do I need to do?
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.
 
 
for-in and for-each iteration order
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[0] = "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.
 
 
What is impacted?
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.
 
 
What do I need to do?
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.
 

 
New security-related features that are available

This section describes new functionality. No action is necessary unless you want to take advantage of this new functionality.
 
 
LoaderContext.allowCodeImport
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 Loader.load with 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 loadBytes:
 
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."
Note that 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 BitmapData.draw.
 
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.
 

 
Where to go from here

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.
 

More Like This