Local Security Basics

In Flash Player 7 and earlier, local SWFs—those loaded from a user’s filesystem using a local path—were freely permitted to perform most of the operations normally governed by Flash Player security rules. For example, while a SWF loaded over HTTP is only permitted (by default) to load text using XML.load() from its own origin domain, a local SWF in Flash Player 7 was permitted to load text from any HTTP URL, or any local filesystem path, using XML.load().

Think of reading a text file from a local path as a privilege called local-read. Consider also that, in Flash Player 7, all SWFs had an additional privilege called net-send, which enables any data to be sent to any Internet location using, for example, an HTTP POST operation via LoadVars.send(). Combine local-read and net-send in a local SWF that an end user has downloaded from an untrusted source and you can see that the local SWF could take the inappropriate step of reading text files off the user’s computer and sending their contents back to a location on the Internet, all without the user’s knowledge.

In Flash Player 8, the simplest summary of the rules for local SWFs is this: By default, local SWFs retain the local-read privilege but lose the net-send privilege; they are not permitted to communicate with the Internet (or any HTTP server) in any way. By changing a setting in a SWF file, a Flash author can elect to have a SWF gain the net-send privilege, in return for giving up the local-read privilege. Finally, authors and users can configure Flash Player to elevate a SWF to a trusted status where it has both privileges—in other words, the SWF will have exactly the privileges it had in Flash Player 7.

What Is Affected

Flash content may be affected depending on two factors: whether it is local content and in which type of Flash Player it is being executed.

Affected SWFs are those loaded from local paths. This includes the following examples of URL forms (among others):

• c: empmy.swf
• file:///c|/temp/my.swf
• /temp/my.swf
• file:///temp/my.swf
• \serversharemy.swf
• file:////server/share/my.swf
• Relative URLs loaded by already-local SWFs

There are several different Flash Player types and each is affected in different circumstances:

• The web-browser players (ActiveX control and Plugin players) enforce local security rules whenever used in a web browser.
• The web-browser players do not always enforce local security rules when used within a non-browser application. If you maintain an application that embeds one of these players, see the section “Flash Player Embedding and Local Security.”
• The stand-alone players enforce local security rules.
• Flash projectors, which can be created from the Macromedia Flash authoring application and from the stand-alone players, do not enforce local security rules. This is because they are executable applications which users must, in general, know to treat with caution.
• The authoring players in Flash do not enforce local security rules because they are used only to test content in development, not to play content from the web.

Sandbox Types

In Flash Player 8, all SWFs (and HTML files, for purposes of SWF-HTML scripting) are placed into one of four types of sandbox:

• Remote: All files from non-local URLs are placed in a remote sandbox. There are many such sandboxes, one for each Internet (or intranet) domain from which files have been loaded. These are the same sandboxes that were introduced in Flash Player 6; they are not changed in Flash Player 8.
• Local-with-filesystem: This is the default sandbox for local files in Flash Player 8. SWFs in this sandbox may not contact the Internet (or any HTTP servers) in any way—for example, they may not pass HTTP URLs to loadMovie(), getURL(), or XML.load(). Because such operations were permitted in Flash Player 7, if a SWF of version 7 or earlier attempts to contact the Internet, this represents a situation where formerly working content may stop working as intended after an end user upgrades from Flash Player 7 to Flash Player 8. Thus, when a SWF of version 7 or earlier attempts to contact the Internet, Flash Player 8 shows a warning dialog box to the user indicating that an attempt to contact the Internet has failed. The warning dialog box contains a button allowing the user to access the Settings Manager, where they may choose to elevate the affected content to local-trusted status (see below).
• Local-with-networking: SWFs in this sandbox may communicate over HTTP but may not read from local file systems. SWFs of any version may opt into this sandbox using a flag set in the SWF itself—in other words, no user involvement is required for a SWF to be placed in this sandbox. This flag may be set using the publish options in Flash 8, or using the Local Content Updater, a free SWF postprocessing utility available from macromedia.com.
• Local-trusted: This sandbox has no restrictions. It offers the same open privileges as all local files were given in Flash Player 7. Any local file may be placed in this sandbox if given authorization by the end user. This authorization may come in two forms: interactively via the Settings Manager or noninteractively via an exectuable installer that creates Flash Player configuration files on the user’s computer.

It may be helpful at this point to look at the appendix of diagrams describing local security.

If a local SWF needs access to the Internet (or an intranet HTTP server), there are two local sandboxes that offer such access. The local-with-networking sandbox is more easily achieved, and all necessary configuration conveniently travels with the SWF itself. The local-trusted sandbox is more powerful, offering greater privileges, but generally takes more effort to achieve and requires configuration information that is separate from the SWF itself. After explaining the details of the local security rules, this article will return to the question of how to decide between these two alternatives.

Global Permissions

Because local files no longer have unrestricted permissions in Flash Player 8, there are situations where Flash permissions may be granted to local files. These are described in the next section.

In general, Flash Player adheres to a principle of requiring global permissions in order to grant permissions to local files. For example, if a remote SWF wishes to permit itself to be scripted by a local-with-networking SWF, it must call System.security.allowDomain(“*”), thus permitting any other loaded SWF to script it. Flash Player does not offer any way to grant permission only to local files; the granting party must be willing to grant permission to all files. This is because Flash Player cannot determine an origin for any local file—the file could have come from anywhere. It is thus not appropriate to permit a local file to perform an action unless the granting party does not care where the file came from.

Be sure not to call System.security.allowDomain(“*”) unless the SWF that does so contains no sensitive information. Do not simply call System.security.allowDomain(“*”) as a cure-all for your security problems—doing so sacrifices protections that your content may need! Take some time to think about the consequences of granting global permissions each time you do so.