Local Security for Cooperating Media

Thus far, we have discussed local security from the point of view of a single SWF operating on its own: No individual SWF may have both local-read and net-send privileges without authorization from the user. But the local security enhancements in Flash Player 8 must also protect Flash Player users when multiple SWFs cooperate with each other. No cooperating set of SWFs can collectively have both local-read and net-send privileges.

Achieving cooperation between SWFs requires two steps. First, one SWF must load another, generally using the ActionScript loadMovie command. Second, the two SWFs must exchange information, using ActionScript variables, method calls, LocalConnection objects, or the like. This exchange of information is sometimes called cross-scripting.

To maintain local security, Flash Player prohibits SWF loading in some cases; in other cases, it permits SWF loading but limits cross-scripting.

SWF loading and cross-scripting are always permitted between SWFs that reside in the same sandbox. So, for example, any local-with-filesystem SWF may load and cross-script any other local-with-filesystem SWF; any local-with-networking SWF may load and cross-script any other local-with-networking SWF; and so on. The restrictions appear when two SWFs from different sandboxes attempt to cooperate.

Table 1 summarizes loading and cross-scripting restrictions between sandboxes; the individual rules appear after. In any cooperation between SWFs, there are two parties. We call the SWF that initiates the cooperation (calls loadMovie or performs cross-scripting) the accessing SWF, and the other SWF the accessed SWF. The labels at the top of the table represent the sandbox of the accessing SWF, and the labels at the left represent the sandbox of the accessed SWF.

Loading Restrictions

The red cells in Table 1 indicate situations where certain SWFs cannot load others (using loadMovie, loadMovieNum, etc.):

• Remote SWFs (those served over HTTP and other non-local protocols) can never load local SWFs.
• Local-with-networking SWFs can never load local-with-filesystem SWFs, or vice versa.
• Local-with-filesystem SWFs can never load remote SWFs. (This actually is a consequence of a rule already discussed: Loading a remote SWF requires calling loadMovie with a remote URL, which is a net-send operation, and thus forbidden to local-with-filesystem SWFs.)

The latter two rules can be worked around when necessary because it is easy to change a SWF from local-with-filesystem to local-with-networking or vice versa.

However, the first rule—that remote SWFs cannot load local SWFs—is absolute. It cannot be worked around, unlike most other security rules in Flash Player. This rule avoids what are called zone escalations, where content in a less privileged zone (a remote SWF) activates content from a potentially more privileged zone (local SWFs). If you find yourself in the unusual position of maintaining a hybrid remote-local application that starts locally installed content when users visit a web page, your best option is to change your entry point, asking users to start by viewing a local SWF (or local projector, local executable, etc) that then activates your online content.

Flash Player has similar rules for calling getURL, which loads browser pages rather than SWFs:

• Remote SWFs cannot call getURL with local URLs
• Local-with-filesystem SWFs may call getURL with local URLs, but when they do so, any query parameters or anchors (parts of the URL that follow a “?” or “#” symbol) will be stripped off

Cross-Scripting Permissions

The yellow cells in Table 1 indicate situations where one SWF may script another, as long as the accessed SWF explicitly grants permission for the operation. These situations include the following:

• A non-trusted local SWF scripting a local-trusted SWF; the local-trusted SWF must grant permission
• A local-with-networking SWF scripting a remote SWF; the remote SWF must grant permission
• A remote SWF scripting another remote SWF from a different domain; the accessed SWF must grant permission (the remote-to-remote rules have not changed from Flash Player 7)

In keeping with the Flash Player global permission principle, the first two of these situations require the accessed SWF to grant permission to accessing SWFs from all sandboxes. This means calling System.security.allowDomain(“*”) or, for LocalConnection objects, providing a LocalConnection.allowDomain handler that returns a true value when provided with a domain argument specifying “localhost.”

Persistent Shared Objects

Flash Player 6 and later support persistent shared objects through the SharedObject class. Persistent shared objects store data on users’ computers. They are usually local shared objects, obtained with SharedObject.getLocal. It is also possible to create persistent remote shared objects; this requires Flash Media Server (formerly Flash Communication Server), and remote shared objects are documented with that product.

Each remote sandbox has an associated store of persistent shared objects. For example, when any SWF from domain1.com reads or writes a persistent shared object, Flash Player will read or write that object in the domain1.com object store. Likewise for a SWF from domain2.com, Flash Player will use the domain2.com store. To avoid name collisions, persistent shared objects are further identified by a path, which defaults to the full path in the URL of the creating SWF, but can be shortened using the localPath parameter to SharedObject.getLocal, which allows other SWFs from the same domain to access a shared object after it is created.

In Flash Player 7 and earlier, all local SWFs shared a single persistent shared object store. Starting with Flash Player 8, there are two local shared object stores. Repeating an earlier pattern, Flash Player ensures that local-with-filesystem SWFs cannot communicate with local-with-networking SWFs—in this case by assigning a separate shared object store to each of these two local sandboxes.

Flash Player assigns local-trusted SWFs to the same shared object store as local-with-filesystem SWFs. This helps ease transitions between local-with-filesystem status (the default) and local-trusted status (which end users may elect as a repair measure for existing local content that stops working as expected). When SWFs make this transition, they retain any shared objects they have created.