Introduction to security

Declarative compared to programmatic security
Client security overview
Deploying secure applications

Adobe® Flash® Player runs applications built as SWF files. Content is delivered as a series of instructions in binary format to Flash Player over web protocols in the precisely described SWF (.swf) file format. The SWF files themselves are typically hosted on a server and then downloaded to, and displayed on, the client computer when requested. Most of the content consists of binary ActionScript instructions. ActionScript is the ECMA standards-based scripting language that Flash uses that features APIs designed to allow the creation and manipulation of client-side user interface elements and for working with data.

The Flex security model protects both client and the server. Consider the following two general aspects to security:

Authorization and authentication of users accessing a server’s resources
Flash Player operating in a sandbox on the client

Flex supports working with the web application security of any J2EE application server. In addition, precompiled applications can integrate with the authentication and authorization scheme of any underlying server technology to prevent users from accessing your applications. The Flex framework also includes several built-in security mechanisms that let you control access to web services, HTTP services, and server-based resources such as EJBs.

Flash Player runs inside a security sandbox that prevents the client from being hijacked by malicious application code.

Note: SWF content running in the Adobe® AIR™ follows different security rules than content running in the browser. For details, see Adobe AIR Security.

Declarative compared to programmatic security

The two common approaches to security are declarative and programmatic. Often, declarative security is server based. Using the server’s configuration, you provide protection to a resource or set of resources. You use the container’s authentication and authorization schemes to protect that resource from unauthorized access.

The declarative approach to security casts a wide net. Declarative security is implemented as a separate layer from the web components that it works with. You set up a security system, such as a set of file permissions or users, groups, and roles, and then you plug your application's authentication mechanism into that layer.

With declarative security, either a user gains access to the resource or they do not. Usually the content cannot be customized based on roles. In an HTML-based application, the result is that users are denied access to certain pages. However, in a Flex environment, the typical result of declarative security is that the user is denied access to the entire application, since the application is seen as a single resource to the container.

Declarative security lets programmers who write web applications ignore the environment in which they write. Declarative security is typically set up and maintained by the deployer and not the developer of the application. Also, updates to the web application do not generally require a refactoring of the security model.

Programmatic security gives the developer of the application more control over access to the application and its resources. Programmatic security can be much more detailed than declarative security. For example, a developer using programmatic security can allow or deny a user access to a particular component inside the application.

Although programmatic security is typically configured by the developer of the application, it usually interacts with the same systems as declarative security, so the relationship between developer and deployer of the application must be cooperative when implementing programmatic security.

Declarative security is recommended over programmatic security for most applications because the design promotes code reuse, making it more maintainable. Furthermore, declarative security puts the responsibility of security into the hands of the people who specialize in its implementation; application programmers can concentrate on writing applications and people who deploy the applications in a specific environment can concentrate on enforcing security policies and take advantage of that context.

Client security overview

When considering security issues, you cannot think of applications as traditional web applications. Applications built with Flex often consist of a single monolithic SWF file that is loaded by the client once, or a series of SWF files loaded as modules or RSLs. Web applications, on the other hand, usually consist of many individual pages that are loaded one at a time.

Most web applications access resources such as web services that are outside of the client. When an application accesses an external resource, two factors apply:

Is the user authorized to access this resource?
Can the client load the resource, or is it prevented from loading the resource, because of its sandbox limitations?

The following basic security rules always apply by default:

Resources in the same security sandbox can always access each other.
SWF files in a remote sandbox can never access local files and data.

You should consider the following security issues related to the client architecture that affect applications.

Flash Player security features

Much of Flash Player security is based on the domain of origin for loaded SWF files, media, and other assets. A SWF file from a specific Internet domain, such as www.example.com, can always access all data from that domain. These assets are put in the same security grouping, known as a security sandbox. For example, a SWF file can load SWF files, bitmaps, audio, text files, and any other asset from its own domain. Also, cross-scripting between two SWF files from the same domain is permitted, as long as both files are written using ActionScript 3.0. Cross-scripting is the ability of one SWF file to use ActionScript to access the properties, methods, and objects in another SWF file. Cross-scripting is not supported between SWF files written using ActionScript 3.0 and files using previous versions of ActionScript; however, these files can communicate by using the LocalConnection class.

Memory usage and disk storage protections

Flash Player includes security protections for disk data and memory usage on the client computer.

The only type of persistent storage is through the SharedObject class, which is embodied as a file in a directory whose name is related to that of the owning SWF file. An application cannot typically write, modify, or delete any files on the client computer other than SharedObject data files, and it can only access SharedObject data files under the established settings per domain.

Flash Player helps limit potential denial-of-service attacks involving disk space (and system memory) through its monitoring of the usage of SharedObject classes. Disk space is conserved through limits automatically set by Flash Player (the default is 100K of disk space for each domain). The author can set the application to prompt the user for more disk space, or Flash Player automatically prompts the user if an attempt is made to store data that exceeds the limit. In either case, the disk space limit is enforced by Flash Player until the user gives explicit permission for an increased allotment for that domain.

Flash Player contains memory and processor safeguards that help prevent applications from taking control of excess system resources for an indefinite period of time. For example, Flash Player can detect an application that is in an infinite loop and select it for termination by prompting the user. The resources that the application uses are immediately released when the application closes.

Flash Player uses a garbage collector engine. The processing of new allocation requests always first ensures that memory is cleared so that the new usage always obtains only clean memory and cannot view any previous data.

Privacy

Privacy is an important aspect of overall security. Adobe products, including Flash Player, provide very little information that would reveal anything about a user (or their computer). Flash Player does not provide personal information about users (such as names, e-mail addresses, and phone numbers), or provide access to other sensitive information (such as credit card numbers or account information).

What Flash Player does provide is basically standardized hardware and software configuration information that authors might use to enhance the user experiences in the environment encountered. The same information is often available already from the operating system or web browser.

Information about the client environment that is available to the application includes:

User agent string, which typically identifies the embedding browser type and operating system of the client
System capabilities such as the language or the presence of an MP3 decoder (see the Capabilities class)
Presence of a camera and microphone
Keyboard and mouse input

ActionScript also includes the ability to replace the contents of the client’s Clipboard by using the setClipboard() method of the System class. This method does not have a corresponding getClipboard() method, so protected data that might be stored in the Clipboard already is not accessible to Flash Player.

About sandboxes

The sandbox type indicates the type of security zone in which the SWF file is operating. In Flash Player, all SWF files (and HTML files, for the purposes of SWF-to-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 are loaded.

local-with-filesystem

The default sandbox for local files. SWF files in this sandbox may not contact the Internet (or any servers) in any way—they may not access network endpoints with addresses such as HTTP URLs.

local-with-networking

SWF file in this sandbox may communicate over the network but may not read from local file systems.

local-trusted

This sandbox is not restricted. Any local file can be placed in this sandbox if given authorization by the end user. This authorization can come in two forms: interactively through the Settings Manager or noninteractively through an executable installer that creates Flash Player configuration files on the user’s computer.

You can determine the current sandbox type by using the sandboxType property of the Security class, as the following example shows:

<?xml version="1.0" encoding="utf-8"?>
<!-- security/DetectCurrentSandbox.mxml -->
<s:Application 
    xmlns:fx="http://ns.adobe.com/mxml/2009"    
    xmlns:mx="library://ns.adobe.com/flex/mx"     
    xmlns:s="library://ns.adobe.com/flex/spark"
    creationComplete="initApp()">
    
    <s:layout> 
        <s:VerticalLayout/> 
    </s:layout>
    
    <fx:Script><![CDATA[
        [Bindable]
        private var mySandboxType:String;

        private function initApp():void {
            mySandboxType = String(Security.sandboxType);
        }
    ]]></fx:Script>

    <s:HGroup>
        <s:Label text="Sandbox Type: "/>                
        <s:Label id="tb1" text="{mySandboxType}"/>              
    </s:HGroup>
</s:Application>The executing SWF file for the previous example is shown below:

When you compile an application, you have some control over which sandbox the application is in. This determination is a combination of the value of the use-network compiler option (the default is true) and whether the SWF file was loaded by the client over a network connection or as a local file.

The following table shows how the sandbox type is determined:

use-network	Loaded	Sandbox type
false	locally	local-with-filesystem
true	locally	local-with-network
true	network	remote
false	network	n/a (causes an error)

Browser security

Flash Player clients can be one of the following four types:

Embedded Flash Player
Debugger version of embedded Flash Player
Stand-alone Flash Player
Debugger version of stand-alone Flash Player

The stand-alone Flash Player runs on the desktop. It is typically used by people who are running applications that are installed and maintained by an IT department that has access to the desktop on which the application runs.

The embedded Flash Player is run within a browser. Anyone with Internet access can run applications from anywhere with this player. For Internet Explorer, the embedded player is loaded as an ActiveX control inside the browser. For Netscape-based browsers (including Firefox), it is loaded as a plug-in inside the browser. Using an embedded player lets the developer use browser-based technologies such as FORM and BASIC authentication as well as SSL.

Browser APIs

Applications hosting the Flash Player ActiveX control or Flash Player plug-in can use the EnforceLocalSecurity and DisableLocalSecurity API calls to control security settings. If DisableLocalSecurity is opened, the application does not benefit from the local-with-networking and local-with-file-system sandboxes. All files loaded from the local file system are placed into the local-trusted sandbox. The default behavior for an ActiveX control hosted in a client application is DisableLocalSecurity.

If EnforceLocalSecurity is opened, the application can use all three local sandboxes. The default behavior for the browser plug-in is EnforceLocalSecurity.

Cross-scripting

Cross-scripting is when a SWF file communicates directly with another SWF file. This communication includes calling methods and setting properties of the other SWF file.

SWF file loading and cross-scripting are always permitted between SWF files that reside in the same sandbox. For example, any local-with-filesystem SWF file can load and cross-script any other local-with-filesystem SWF file; any local-with-networking SWF file can load and cross-script any other local-with-networking SWF file; and so on. The restrictions appear when two SWF files from different sandboxes or two remote SWF files with different domains attempt to cooperate.

For SWF files in the remote sandbox, if two SWF files were loaded from the same domain, they can cross-script without any restrictions. If both SWF files were loaded from a network, but from different domains, you must provide permissions to allow them to cross-script.

To enable cross-scripting between SWF files, use the Security class’s allowDomain() and allowInsecureDomain() methods.

You call these methods from the called SWF file and specify the calling SWF file’s domain. For example, if SWF1 in domainA.com calls a method in SWF2 in domainB, SWF2 must call the allowDomain() method and specifically allow SWF files from domainA.com to cross-script the method, as the following example shows:

import flash.system.Security; 
Security.allowDomain("domainA.com");

If the SWF files are in different sandboxes (for example, if one SWF file was loaded from the local file system and the other from a network) they must adhere to the following set of rules:

Remote SWF files (those served over HTTP and other non-local protocols) can never load local SWF files.
Local-with-networking SWF files can never load local-with-filesystem SWF files, or vice versa.
Local-with-filesystem SWF files can never load remote SWF files.
Local-trusted SWF files can load SWF files from any sandbox.

To facilitate SWF-to-SWF communication, you can also use the LocalConnection class. For more information, see Using the LocalConnection class.

ExternalInterface

You use the ExternalInterface API to let your application call scripts in the wrapper and to allow the wrapper to call functions in your application. The ExternalInterface API consists primarily of the call() and addCallback() methods in the flash.net package.

This communication relies on the domain-based security restrictions that the allowScriptAccess and allowNetworking properties define. You set the values of the allowScriptAccess and allowNetworking properties in the SWF file’s wrapper. For more information, see About the object and embed tags.

By default, the application and the HTML page it is calling must be in the same domain for the call() method to succeed. For more information, see Communicating with the wrapper.

The navigateToURL() method

The navigateToURL() method opens or replaces a window in the Flash Player’s container application. You typically use it to launch a new browser window, although you can also embed script in the method’s call to perform other actions.

This usage of the navigateToURL() method relies on the domain-based security restrictions that the allowScriptAccess and allowNetworking parameters define. You set the values of the allowScriptAccess and allowNetworking parameters in the SWF file’s wrapper. For more information, see About the object and embed tags.

Caching

Applications reside entirely on the client. If the browser loads the application, the application SWF file, plus externally loaded images and other media files, are stored locally on the client in the browser’s cache. These files reside in the cache until cleared.

Storing a SWF file in the browser’s cache can potentially expose the file to people who would not otherwise be able to see it. The following table shows some example locations of the browser’s cache files:

Browser or operating system	Cache location
Internet Explorer on Windows XP	C:\Documents and Settings\username\Local Settings\Temporary Internet Files
Firefox on Windows XP	C:\Documents and Settings\username\Application Data\Mozilla\Firefox\Profiles\username.default\Cache
UNIX	$HOME/.mozilla/firefox/username.default/Cache/

These files can remain in the cache even after the browser is closed.

To prevent client browsers from caching the SWF file, try setting the following HTTP headers in the SWF file’s wrapper:

Cache-control: no-cache, no-store, must-revalidate, max-age=-1 
Pragma: no-cache, no-store 
Expires: -1

Note that in some cases, setting the Pragma header to "no-cache" can cause a runtime error with GET requests over SSL with the HTTPService class. In this case, setting just the Cache-control header should work.

Marc Speck has a blog entry that describes the issue and presents several solutions.

Trusted sites and directories

The browser security model includes levels of trust applied to specific websites. Flash Player interacts with this model by assigning a sandbox based on whether the browser declared the site of the SWF file’s origin trusted.

If Flash Player loads a SWF file from a trusted website, the SWF file is put in the local-trusted sandbox. The SWF file can read from local data sources and communicate with the Internet.

You can also assign a SWF file to be in the local-trusted sandbox when you load it from the local file system. To do this, you configure a directory as trusted by Flash Player (which results in the SWF file being put in the local-trusted sandbox) by adding a FlashPlayerTrust configuration file that specifies the directory to trust. This requires administrator access privileges to the client system, so it is typically used in controlled environments. Users can also define a directory as trusted by using the Flash Player User Settings Manager. For more information, see the Flash Player documentation.

Deploying secure applications

When you deploy an application, you make the application accessible to your users. The process of deploying an application is dependent on your application, your application requirements, and your deployment environment. You can employ some of the following strategies to ensure that the application you deploy is secure.

Deploying local SWF files versus network SWF files

Client computers can obtain individual SWF files from a number of sources, such as from an external website or a local file system. When SWF files are loaded into Flash Player, they are individually assigned to security sandboxes based on their origin.

Flash Player classifies SWF files downloaded from the network (such as from external websites) in separate sandboxes that correspond to their website origin domains. By default, these files are authorized to access additional network resources that come from the specific (exact domain name match) site. Network SWF files can be allowed to access additional data from other domains by explicit website and author permissions.

A local SWF file describes any file referenced by using the “file” protocol or a UNC path, which does not include an IP address or a qualifying domain. For example, “\\test\test.swf” and “file:\test.swf” are considered local files, while “\\test.com\test.swf” and “\192.168.0.1\test.swf” are not considered local files.

Local SWF files from local origins, such as local file systems or UNC network paths, are placed into one of three sandboxes: local-with-networking, local-with-filesystem, and local-trusted.

When you compile the application, if you set the use-network compiler option to false, local SWF files are placed in the local-with-filesystem sandbox. If you set the use-network compiler option to true, local SWF files are placed in the local-with-networking sandbox.

Local SWF files that are registered as trusted (by users or by installer programs) are placed in the local-trusted sandbox. Users can also reassign (move) a local SWF file to or from the local-trusted sandbox based on their security considerations.

Deploy checklist

Before you deploy your application, ensure that your proxy servers, firewalls, and assets are configured properly. Adobe provides a deployment checklist that you can follow. For more information, see Deployment checklist.

Remove wildcards

If your application relies on assets loaded from another domain, and that domain has a crossdomain.xml file on it, remove wildcards from that file if possible. For example, change the following:

<cross-domain-policy> 
    <site-control permitted-cross-domain-policies="all"/> 
    <allow-access-from domain="*" to-ports="*"/> 
</cross-domain-policy>

to this:

<cross-domain-policy> 
    <site-control permitted-cross-domain-policies="by-content-type"/> 
    <allow-access-from domain="*.myserver.com" to-ports="80,443,8100,8080" /> 
</cross-domain-policy>

Also, set the value of the to-ports attribute of the allow-access-from tag to ensure that you are only allowing necessary ports access to the resources.

Check your application for calls to the allowDomain() and allowInsecureDomain() methods. During development, you might pass these methods a wildcard character (*), but now restrict those methods to allowing requests only from the necessary domains.

Deploy assets to WEB-INF

In some deployments, you want to make assets such as data files accessible to the application, but not accessible to anyone requesting the file. If you are using a J2EE-based server, you can deploy those files to a subdirectory within the WEB-INF directory. Based on J2EE security constraints, no J2EE server can return a resource from the WEB-INF directory to any client request. The only way to access files in this directory is with server-side code.