Flash Player Security in Flash MX 2004 and Flash 8

Flash Player 8 has made enhancements to the security model, in which Flash applications and SWF files on a local computer are not allowed to communicate with both the Internet and the local file system by default. A local SWF file is a SWF file that is locally installed on a user’s computer, not served from a website, and does not include projector (EXE) files. This section provides an overview of the new security model.

Note: The restrictions that I discuss pertaining to local file security do not affect SWF files that are on the Internet.

Local File Security and Flash Player 8

When you create a FLA file, you can indicate whether a SWF file is allowed to communicate with a network or with a local file system when running as a local file. In previous versions of Flash Player, local SWF files could interact with other SWF files and load data from any remote or local location. In Flash Player 8, a SWF file cannot make connections to the local file system and the Internet. This is a safety change, so a SWF file cannot read files on your hard disk and then send the contents of those files across the Internet.

This security restriction affects all locally deployed content, whether it is legacy content (a FLA file created in an earlier version of Flash) or content created in Flash 8. Suppose you deploy a Flash application, using Flash MX 2004 or earlier, that runs locally and also accesses the Internet. In Flash Player 8, this application now prompts the user for permission to communicate with the Internet.

When you test a file on your hard disk, there are a series of steps to determine whether the file is a local trusted document or a document that is potentially not trusted. If you create the file in the Flash authoring environment (for example, when you select Control > Test Movie), your file is trusted because it is in a test environment.

In Flash Player 7 and earlier, local SWF files had permissions to read from both a local file system and the network (such as the Internet). In Flash Player 8, local SWF files can have the following levels of permission:

• Access the local file system only (default): A local SWF file can read from the local file system and universal naming convention (UNC) network paths but cannot communicate with the Internet
• Access the network only: A local SWF file can access the network (such as the Internet) but not the local file system where it is installed
• Access to the local file system and the network: A local SWF file can read from the local file system where it is installed, read and write to and from servers, and cross-script other SWF files on either the network or the local file system (these files are trusted and behave just as they did in Flash Player 7)

You can set the file to access the local file system only, or access the network using the Publish Settings dialog box in Flash 8. If you want the file to access the local file system and the network, you need to grant it permission using a configuration file. Alternatively, you have the option of setting permission using the Global Security Settings manager, which you can open when prompted in a warning dialog box.

Working with Legacy Files

Some legacy FLA and SWF files (created with Flash MX 2004 and earlier) might not work when you test or deploy them locally (on a hard disk) because of security changes in Flash 8. This might happen when a SWF file tries to access websites outside its domain. In such a case, you need to implement a cross-domain policy file.

You might have FLA or SWF files created in Flash MX 2004 or earlier that have been distributed to users who do not use the Flash 8 authoring tool but have upgraded to Flash Player 8. If your locally tested or deployed legacy content (an old SWF file on a user’s hard disk) breaks because it tries to communicate with the Internet when playing in Flash Player 8, you must rely on users to trust your content in order for it to play properly (by clicking a button in a dialog box).

If you published SWF files for Flash Player 7 or earlier that are deployed on local computers and communicate with the Internet, users must allow Internet communication. Users can stop content from breaking by adding the location of the SWF file on their local computer to the trusted sandbox in the Settings Manager.

To fix SWF files for local playback, use any of the following options:

• Redeploy Run the Local Content Updater: The Local Content Updater reconfigures your SWF file to make it compatible with the Flash Player 8 security model. You reconfigure the local SWF file so it can either access only the network or only the local file system.
• Republish and redeploy: Republish the file with Flash Basic 8 or Flash Professional 8. The authoring tool requires you to specify in the Publish Settings dialog box whether a local SWF file can access the network or the local file system, but not both. If you specify that a local SWF file can access the network, you also must enable permissions for that SWF file (and all local SWF files) in the SWF, HTML, data, or server files that it accesses.
• Deploy new content: Use a configuration (CFG) file in the #Security/FlashPlayerTrust folder. You can use this file to set network and local access permissions.

Note: Any of these options require that you either republish or redeploy your SWF file.

Changes to System.security

You’ll also find minor changes to System.security.allowDomain System.security.allowInsecureDomain, pertaining to files that you deploy on the Internet. Flash Player 8 changed the way it handles System.security.allowDomain.

A Flash 8 SWF file that calls System.security.allowDomain with any argument, or any other SWF file that uses the wildcard (*) value, permits access only to itself. There is now support for a wildcard (*) value, for example: System.security.allowDomain("*") and System.security.allowInsecureDomain("*").

If a SWF file of version 7 or earlier calls System.security.allowDomain or System.security.allowInsecureDomain with an argument other than a wildcard (*), this will affect all SWF files of version 7 or lower in the calling SWF file’s domain, as it did in Flash Player 7. However, this kind of call does not affect any Flash Player 8 (or later) SWF files in the calling SWF file’s domain. This helps minimize legacy content breaking in Flash Player.