Setting security controls within the HTML code

When a SWF is embedded within HTML, there are several flags that can be set that tell Flash Player the permissions the SWF file has to access content either from the browser or on the network. These flags are useful for sites that may link to untrusted SWF files from third-party developers.

In addition to the strategies described below, refer to the "How to restrict SWF content from HTML" blog post for additional information.

Using allowScriptAccess

Related threats: Script injection into the browser

To learn more about controlling access to HTML scripts, see the section entitled Controlling outbound URL access in the Programming ActionScript 3.0 for Flash documentation.

The allowScriptAccess setting has been available since Flash Player 6,0,40,0. It determines whether a parent SWF file and any SWF files loaded by the parent SWF file can make outbound scripting calls to the browser through commands such as fscommand() and ExternalInterface() or sending "javascript://{code}" statements to getURL (in ActionScript 2.0) and navigateToURL (in ActionScript 3.0). Inbound calls from HTML to ActionScript code are controlled by the Security.allowDomain() ActionScript call, which is discussed later in this document.

When you grant access to the SWF file, remember that you are essentially granting both read and write access to the entire HTML page.

The three possible settings for allowScriptAccess are:

• always: The SWF file is completely trusted to communicate with the browser regardless of the domain used to load it. All SWF files loaded by this SWF are also granted permission to communicate with the browser. This is the default for SWF files compiled for compatibility with Flash Player 7 and earlier when using versions of Flash Player prior to 9,0,124,0.
• sameDomain: If the SWF and the hosting HTML page are located within the same domain, then they may communicate with each other. If you are using a version of Flash Player prior to 9,0,124,0, this is the default for SWF files compiled for compatibility with Flash Player 8 and later. If you are using Flash Player 9,0,124,0 or later, then it is the default for all content regardless of the Flash Player version for which the content was compiled.
• never: The SWF and the browser are never allowed to communicate with each other through JavaScript. This setting has been deprecated. Please see the following TechNote for more information: Deprecation of the "never" setting for allowScriptAccess.

It is also important to note that the allowNetworking tag can affect script access within the browser and will supersede the settings used for the allowScriptAccess tag.

Review the highlighted sections in the following code example:

<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'>
<param name='allowScriptAccess' value='never'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' allowScriptAccess='never'/>
</object>

Understanding allowNetworking

Related threats: Script injection into the browser, cross-domain privilege escalation

To augment the information provided below, read the Restricting networking APIs section of the Programming ActionScript 3.0 for Flash documentation.

The allowNetworking feature was added in Flash Player 9 to prevent a SWF from making external networking calls through the browser or through ActionScript networking calls. The allowNetworking settings will supersede the allowScriptAccess settings since methods controlled by the allowScriptAccess tag are a subset of the overall class of ActionScript networking methods:

The three possible settings for allowNetworking are:

• all: The SWF is completely trusted to make any network connections. Communication with the browser will be controlled by allowScriptAccess. This is the default setting.
• internal: The SWF is prevented from making navigateToURL(), fscommand() and ExternalInterface.call() ActionScript 3.0 commands. For ActionScript 2.0 developers, getURL(), MovieClip.getURL(), fscommand(), and ExternalInterface.call() will be restricted. This overrides any allowScriptAccess setting and blocks the SWF from communicating with the browser. All networking calls must be made internally inside the SWF.
• none: This is the most restrictive tag that can be set within the HTML. This will block the SWF from performing any external communication.

For ActionScript 3.0, the blocked networking methods include sendToURL(),  FileReference.download(), FileReference.upload(), Loader.load, LocalConnection.connect(), NetConnection.connect(), NetStream.play(), Security.loadPolicyFile(), SharedObject.getLocal(), SharedObject.getRemote(), Socket.connect, Sound.load(), URLLoader.load(), URLStream.load(), XMLSocket.connect(), System.security.loadPolicyFile(), as well as those methods blocked by the internal setting.

For ActionScript 2.0, the blocked networking methods include XML.load(), XML.send(), XML.sendAndLoad(), LoadVars.load(), LoadVars.send(), LoadVars.sendAndLoad(), loadVariables(), loadVariablesNum(), MovieClip.loadVariables(), NetConnection.connect(), NetStream.play(), loadMovie(), loadMovieNum(), MovieClip.loadMovie(), MovieClipLoader.loadClip(), Sound.loadSound(), LocalConnection.connect(), LocalConnection.send(), SharedObject.getLocal(), SharedObject.getRemote(), FileReference.upload(), FileReference.download(), System.security.loadPolicyFile(), XMLSocket.connect(), as well as those methods blocked by internal setting.

It is also not possible to reference external media in an <img> tag in the htmlText property of a TextField object (because a SecurityError exception is thrown). Symbols from an imported shared library added in the Flash authoring tool (not ActionScript) are blocked at run time.

Review the highlighted sections in the code example below:

<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'>
<param name='allowNetworking' value='none'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' allowNetworking='none'/>
</object>

allowNetworking supersedes the allowScriptAcess methods

The results of combining the allowNetworking and allowScriptAccess flags are shown in Table 1.

Table 1. Network and access settings for different levels of security

allow ScriptAccess	allowNetworking
	All	Internal	None
Always	The SWF has full access to communicate with the browser and the network. This is the least secure setting.	The allowNetworking setting will override the allowScriptAccess setting and disallow access to the browser. The SWF is still able to leverage internal APIs such as sockets and loaders to communicate with the network.	The allowNetworking setting will override the allowScriptAccess setting and prevent the SWF from communicating to the browser and the network.
SameDomain	The SWF can talk to the HTML container if they are both within the same domain. All internal networking APIs are allowed.	The allowNetworking setting will override the allowScriptAccess setting and disallow access to the browser. The SWF is still able to leverage internal APIs such as sockets and loaders to communicate with the network.	The allowNetworking setting will override the allowScriptAccess setting and prevent the SWF from communicating to the browser and the network.
Never (deprecated)	The SWF can not make calls to the browser but it can make network calls using internal APIs such as sockets and loaders.	This SWF can not communicate with the browser. The SWF is still able to leverage internal APIs such as sockets and loaders to communicate with the network.	The allowNetworking setting prevent the SWF from communicating to the browser and the network. This is the most secure setting.

Understanding that SWFs are code

When you make the decision to host SWF content on a particular domain, it is important to remember that SWF files are code. By default, SWF files will have the same permissions on the hosting domain as JavaScript. Therefore, developers should not host untrusted code on the same domain as trusted code.

One reason is that when a SWF is referenced without any surrounding HTML, such as when a user clicks a link that points directly to the SWF, the defaults for allowScriptAccess and allowNetworking are applied, granting the SWF access to the DOM. This attack may be used by an attacker to conduct cross-site scripting or other malicious attacks. Adobe strongly recommends against mixing trusted and untrusted content on the same domain. The best place to host untrusted content is on a separate IP address that does not have a domain name associated with it. See the section "Segmenting SWFs from trusted content" elsewhere in this article for more information.

Some sites may try to mix trusted and untrusted content on the same domain by placing the untrusted content in a non-web accessible directory and carefully controlling access through a CGI. This implementation is difficult to implement correctly, and developers should take into account all of the permissions that a SWF is granted by being hosted on the same domain as trusted content. For instance, cross-scripting and LocalConnections are allowed by default to SWFs hosted from the same domain.

Controlling full-screen mode

Related threats: Spoofing

To find out more about working in full-screen mode, read Exploring full-screen mode in Flash Player 9.

You can control the display of full-screen mode using the features included in Flash Player. A website hosting third-party SWF files may not wish to allow the videos to go into full screen mode and overlay the site's content. Essentially, full-screen display could result in end-users being tricked into believing that they are interacting with the hosting website—when in reality they are interacting with the third-party SWF file. By default, the allowFullScreen option is set to false.

Adobe has included other controls to limit this scenario: The user must initiate full-screen mode with a mouse click or a keypress event. Upon invoking full-screen display, the end-user will receive an overlay dialog box warning them they are viewing the SWF in full-screen mode with instructions on how to exit. Users cannot enter data into text input fields while the SWF is displayed in full-screen mode. Users and administrators also have the option to prevent full-screen mode within their mms.cfg file.

Review the highlighted sections in the code example below:

<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'>
<param name='allowFullScreen' value='false'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' AllowFullScreen='false'/>
</object>

User-initiated action requirements

Related threats: Spoofing

To find out more about user-initiated action requirements, read User-initiated action requirements in Flash Player 10.

Starting with Flash Player 10, Adobe has added user-initiated action (UIA) requirements around several critical APIs that provide prompts to the user. When an ActionScript API function has a UIA requirement, that function can be called only in response to a user action such as a mouse click or key press. These additions were made in order to prevent potentially harmful actions from being taken by malicious SWF files without the user's consent. These actions include writing to the user's Clipboard, going into full-screen mode, creating pop-up windows, launching a FileReference dialog box, and certain POST operations. You can find a fuller description of these in the article, User-initiated action requirements in Flash Player 10.

Page 4 of 13

Previous Page

Next Page