Menu Search Sign up

Flash Security

Secure Compiler Settings

Flash Player developers should try to compile his SWF application to be compatible with newer versions of Flash Player. Newer versions of Flash Player frequently contain important security updates and features which can help to ensure that SWF files are not misused on the hosted website.
 
All modern versions of Flash Player include an auto-update feature to notify users when a new version of the player is available and this has been highly successful in getting the majority of Flash Player users migrated to new versions quickly.
 
Additionally, Flash Player developers should leverage ActionScript 3.0 to be able to use the better security utilities and functions. For example, in ActionScript 3.0, input controls within the language are more centralized than in ActionScript 2.0 or earlier. 
 
When compiling your SWF code, the Protect From Import and Permit Debugging flags use an MD5 hash to password-protect your SWF files from being imported into a Flash authoring tool. However, this protection is not a very strong protection for authoring tools that choose to honor it. A determined attacker could still decompile the SWF file to get the source code or strip the debugging flag from the binary. The MD5 hash used by these flags is known to be subject to brute force dictionary-based attacks. Therefore, SWF files should not be considered to be a black box application even with the "Protect From Import and 
Permit Debugging" flags set. Any sensitive data or secrets stored within a SWF can easily be found. Developers should therefore not store static passwords, encryption keys or other sensitive data within the source code of a SWF file.
 
When compiling SWF applications, it is a security best practice to remove all debug code from the final production releases. The Omit Trace Actions flag in Flash development environments tells the compiler to remove any trace commands when creating the compiled SWF file. 

Mitigating Spoofing Attacks

The stage size of your SWF application should be set to a minimum of 215 pixels wide and at least 138 pixels high so that Flash Player messages from shared objects, microphone, camera and other components can be displayed fully to the user. The area of the stage displaying the dialog box should also be visible with the default window mode set, to protect against spoofing and clickjacking attacks.
 
Consider the following spoofing attack scenario: 
  1. The loading SWF imports the remote SWF file into its security domain
  2. The remotely loaded SWF can try to render its controls over the top of the loading SWF, in an attempt to perform a spoofing attack. 
  3. if developers do not set masks on Loaders to limit the remote SWF file to a particular area of the stage, then the loaded SWF can overlay the parent SWF, hijacking control from the loading SWF file. 
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. You can control the display of full-screen mode using the features included in Flash Player.  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.

User Initiated Action

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

The allowScriptAccess and allowNetworking Settings

When a SWF is embedded within HTML, there are 2 flags that can be set that tell Flash Player the permissions the SWF file has to access browser content and network resources. These 2 flags are useful for sites that may link to third-party untrusted SWF files.
 
In Flash Player ActionScript:
  • The fscommand(), ExternalInterface.call(), CallLabel(), CallFrame() functions let a SWF file communicate with the JavaScript in the web page that embeds the SWF file.
  • The getURL, navigateToURL functions load a document from a specific URL into a window. 
The allowScriptAccess setting, available since Flash Player 6,0,40,0, determines whether a parent SWF file and any SWF files loaded by the parent SWF file can make above function calls. 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. 
  • sameDomain: If the SWF and the hosting HTML page are located within the same domain, then they may communicate with each other. This is the default setting.
  • never: The SWF and the browser are never allowed to communicate with each other through JavaScript. This setting has been deprecated. 
In the following example, MyMovie.swf file is loaded from the download.adobe.com domain. And if the web page that has the following <object> code is from www.adobe.com domain, then the MyMovie.swf file cannot access the JavaScript in the web page:
 
<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='sameDomain'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' allowScriptAccess='sameDomain'/>
</object>
 
The allowNetworking feature was added in Flash Player 9 to prevent a SWF from making external networking calls 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. The SWF is prevented from making getURL(), MovieClip.getURL(), fscommand(), and ExternalInterface.call()  ActionScript 2.0 commands. This overrides any allowScriptAccess setting and blocks the SWF from communicating with the browser. All networking calls must be made internally inside the SWF with other function calls, not via the browser with the function calls just mentioned.
  • 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 networking methods impacted by the allowNetworking setting 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().
 
For ActionScript 2.0, the networking methods impacted by the allowNetworking setting  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().
 
Cross-Domain Policy File (crosdomain.xml)
 
One of the most common tasks you may want to do in your SWF application is to fetch images, sounds, or other data from a remote website. If the content is from a different domain than the requesting SWF file, then Flash Player will check with the remote domain to confirm whether you have permission to access that content.
 
Let's briefly review the same-origin policy used by browsers: the same-origin policy will allow a piece of content on www.a.com to access all of the other data associated with www.a.com. The site www.a.com can also include an iframe showing the web page for www.b.com. However, the same-origin policy prohibits www.a.com from accessing www.b.com's cookies or interacting with the JavaScript on www.b.com's page.
 
By default, Flash Player will follow the same-origin policy used by browsers which says that content within a single domain can access all the other content and data hosted on the same domain, but not on different domains. Note this means a Flash Player SWF content can always request content from other domains but it can not directly access the data belonging to those other domains. 
 
How does Flash Player determine if 2 domains are the same or different? 
 
First, Flash Player considers the full domain name used to establish the connection to be its security domain. For Flash Player, a SWF file's domain is defined by where the SWF file is hosted. If a web page at the domain www.a.com includes an object tag to load a SWF from the domain www.b.com, then the SWF considers its security domain to be defined by www.b.com. Other SWF files hosted on the www.a.com site will not have full access to the SWF loaded from the www.b.com site because they are loaded from different security domains. Flash Player matches on the complete domain name and therefore the domain www.a.com is considered to be a different security domain from the domain home.a.com. 
 
Second, Flash Player also separates content loaded from www.a.com over HTTPS and content 
loaded from www.a.com over HTTP into separate security domains. 
 
Lastly, Flash Player acknowledges the port used to load SWF content. Therefore, Flash will consider http://www.a.com:80 to be a different site than http://www.a.com:8080.
 
In Flash Player, cross-domain files (crossdomain.xml) can be used for expanding the same-origin policy to allow multiple domain names to be considered part of the same origin. 
 
Suppose the SWF file from www.a.com wants to load remote content from www.b.com. The site www.b.com places a crossdomain.xml file in the directory of the content or one its parent directories, allowing SWF files from www.a.com access:
 
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
  <!-- This is the only cross-domain policy file for this server -->
  <site-control permitted-cross-domain-policies="master-only"/>
   <!-- Administrators can set multiple entries with a wildcard on the sub-domain to avoid setting domain="*" -->
   <allow-access-from domain="www.a.com" />  
   <allow-access-from domain="*.mysite.com" />  
   <allow-access-from domain="*.myothersite.com" /> 
</cross-domain-policy>
 
When the SWF file from www.a.com needs access to www.b.com content, Flash Player requests the crossdomain.xml file from www.b.com, to determine whether the current domain is allowed to load the remote domain's content. If the current domain is not listed in the crossdomain.xml file or the crodomain.xml file does not exist, then access to the content is denied by the Flash Player and an exception will be thrown when you attempt to access the data from within the SWF files that come from www.a.com.
 
Flash Player version 7 and later have restrictions preventing HTTP loaded SWFs accessing resources served over HTTPS. These restrictions are in place by default to prevent untrusted SWF files loaded over HTTP from accessing sensitive data that was securely communicated to trusted SWF files loaded over HTTPS. SWF files loaded over HTTP are untrusted because they are subject to man-in-the-middle attacks. A man-in-the-middle attack is where someone sitting on the network between the end-user and the server alters or replaces the SWF file while it is in transit. Man-in-the-middle attacks are frequently executed in places such as wireless networks.
 
It is possible to override these protections by setting the secure flag for the domain to "false" within the crossdomain.xml file. This practice is not recommended. If allowing communication from HTTP SWF files to HTTPS protected data is absolutely necessary, try to limit the exposure of the HTTPS protected data to the HTTP loaded SWF file. For instance, you would want to avoid setting the secure flag to "false" for the entire website and instead place the cross-domain permission in a specific sub-directory.
 
If you need to allow HTTP-loaded SWF files to communicate with HTTPS-loaded SWF files, then a cross-domain policy file with a secure flag of "false" is not necessary because cross-domain policy files do not govern SWF-to-SWF communication.
 
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
   <!-- This is a master-policy file -->
   <site-control permitted-cross-domain-policies="master-only"/>
   <!-- This says that http://www.mysecuresite.com can access this site's HTTP data -->
   <!-- SWFs on https://www.mysecuresite.com can access this site's HTTPS data -->
   <!-- SWFs on http://www.mysecuresite.com can not access this site's HTTPS data -->
       <allow-access-from domain="www.mysecuresite.com" secure="true" />
</cross-domain-policy>
 
Starting with Flash Player 9,0,124,0, the allow-http-request-headers-from tag and the headers tag within the crossdomain.xml file define weather and which headers are allowed to be sent to the domain hosting the cross-domain policy
 
 <?xml version="1.0"?>
   <!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
   <cross-domain-policy>
   <!-- This domain can accept the HTTP Request headers MyHeader and MyOtherHeader from a SWF file on www.example.com -->
      <allow-http-request-headers-from domain="www.example.com" headers="MyHeader,MyOtherHeader" secure="true"/>
   </cross-domain-policy>

Socket Policy File

Socket policy files define what socket connections are permitted to the domain. 
 
// Use an XMLSocket request to port 843 in order to download a policy
// file allowing access to 456
System.security.loadPolicyFile("xmlsocket://socks.mysite.com:843");
// Connect to port 456
mySocket.connect("socks.mysite.com", 456);
// The crossdomain.xml file on port 123 allowing access to 456
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for xmlsocket://socks.mysite.com -->
<cross-domain-policy> 
   <!-- This is a master-policy file -->
   <site-control permitted-cross-domain-policies="master-only"/>
   <!-- Instead of setting to-ports="*", administrator's can use ranges and commas -->
   <!-- This will allow access to ports 123, 456, 457 and 458 -->
       <allow-access-from domain="socks.mysite.com" to-ports="123,456-458" />
</cross-domain-policy>
 
In addition, socket policy files support a secure flag. Setting this flag to "true" within an <allow-access-from> directive informs Flash Player that only SWF files served over HTTPS are allowed to connect to the specified port. By default this flag is assumed to be false. It is not a best practice to rely on this flag for remote sockets since socket policy files are currently fetched over insecure protocols and are subject to man-in-the-middle attacks. Therefore, an attacker may change the value of the flag while it is transit. This flag may be appropriate for localhost connections where man-in-the-middle attacks are far less likely.

Do Not Mix Trusted and Untrusted Content on the Same Domain

When you make the decision to host SWF content on a particular domain, it is important to remember that SWF files are code. Therefore, developers should not host untrusted SWF files on the domain where trusted SWF files and other trusted content are hosted.
 
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 of the page the user is viewing from the same domain. 

Communicating between SWFs

Flash Player provides several methods for communication between SWF files depending on the developers needs. Each of the methods includes a cross-domain communication capability, and it is important to understand these cross-domain communication capabilities:
  • When 2 SWF files communicate, the flash.system.Security.allowDomain() method is used to allow access to remote domains. 
  • The SharedEvents function allows a loaded SWF to propagate event data to the parent and vice-versa.
  • The LocalConnection.allowDomain() function allows multiple remote SWFs to communicate to the SWF with the LocalConnection.

Cross-Site Scripting (XSS) Attack

Most of the popular web browsers will allow you to write javascript where you normally put the url address. 
  • Suppose the target SWF takes a URL value from a FlashVar and sends that information to a navigateToURL or a getURL command. 
  • An attacker may try to replace the original URL value of the FlashVar with a "javascript:" URL. 
  • JavaScript URLs sent to the browser through getURL or navigateToURL methods will execute within the context of the domain hosting the SWF. 
  • The javascript: URL can contain any set of JavaScript commands including commands to steal the cookies from the domain and forward them to a third-party site. 
  • A cross-site scripting attack could also occur if a malicious remote SWF is imported into the trusted SWF and then the remote SWF calls a javascript: URL.

Cross-Domain Privilege Escalation

Cross-domain loading may allow a remote SWF to have unintended access to the loader's domain and data. Here is how it can happen:
  1. The loading SWF imports the remote SWF file into its security domain
  2. The loaded SWF could gain access to the parent (loading) SWF's data and relay that data back to an attacker. 
  3. The loaded SWF could also possibly inject script into the loaded SWF file's web page, depending on settings within loading SWF's web page

Malicious Data Injection

A Flash application may receive malicious data injection from several types of interfaces. 
 
FashVars
 
It is common for FlashVars to be set via the Object tag within the HTML. These variables can also be set via the URL, making it trivial for an attacker to alter their values. If the SWF takes the FlashVar value as the URL of a remote SWF, then the attacker could alter the URL to point to a malicious SWF instead. 
 
LocalConnection
 
Malicious data injection can also be done when a SWF file obtains data from a LocalConnection. When a SWF file obtains data from a LocalConnection, the SWF file remotely loads variables from a server. If you do not perform data validation on the remotely obtained data, malicious data injection can occur.
 
Importing data from another SWF file
 
Malicious data injection can also be done when a SWF file imports data from another SWF file. If you do not perform data validation on the remotely obtained data, malicious data injection can occur.
 
Script injection into the browser
In some instances, website owners may host third-party untrusted SWF files on their site. If the website owners grant the third-party untrusted SWF files read and write access to their HTML or JavaScript code, it could allow an attacker to rewrite the entire page or redirect the users from the trusted site to a phishing site. 

Insufficient Authorization Restrictions

Excessive cross-domain permissions may allow relay attacks, spoofing, data theft or other attacks. 
 
For example, a malicious SWF file may try to exploit overly permissive cross-domain policy file permissions set on a remote website in order to steal protected data from a remote website. 
 
Another example might be an untrusted SWF that is able to send malicious data to another domain via a LocalConnection. Weak domain restrictions can occur when wildcards are misused in allowDomain methods or cross-domain files.

Unauthorized Access to Data in Transit

An attacker may try to read or alter data sent over unencrypted channels such as RTMP and HTTP. If the SWF file is performing critical functions (such as  collecting credit card data within a shopping cart), then the attacker could potentially view that data. An attacker may also try to manipulate traffic and 
attempt to replace the trusted SWF files with malicious SWF files before they reach the end-user.
 
Vulnerabilities for this threat include when secure communication channels such as HTTPS or RTMPS are not used to protect sensitive data.
 
Insecure communications can also occur when SWF files loaded over HTTP can access the data of SWF files loaded over HTTPS. By default, an HTTP-loaded SWF file may not access data from SWF files loaded over HTTPS. However, if data is shared between an HTTP SWF and an HTTPS SWF then the data may be transmitted over an insecure channel. This can occur if an allowInsecureDomain method is misused or when the secure flag is set to false in a crossdomain.xml file.

Cross-site Request Forgery

Cross-site request forgery (CSRF) is an attack which forces or coaxes an end user to execute unwanted actions on a web application in which he/she is currently authenticated.
 
Due to the current design of the web, protections against these attacks are currently being implemented by the websites themselves and not by the browser or its clients. 
 
Since Flash Player utilizes the browser to make web requests, Flash Player can be used as a tool in performing cross-site request forgery attacks.

DNS Rebinding

Flash Player permits SWF movies to open TCP sockets to arbitrary hosts, provided the destination
serves an XML policy authorizing the movie’s origin. Flash Player is vulnerable to the following rebinding
attack:
 
First, the client’s web browser visits a malicious web site that embeds a SWF movie.
 
Second, the SWF movie opens a socket on a port less than 1024 to attacker.com, bound to the attacker’s IP address.
 
Third, Flash Player sends <policy-file-request />, and the attacker responds with the following XML:
 
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" to-ports="*" />
</cross-domain-policy>
 
Fourth, the SWF movie opens a socket to an arbitrary port number on attacker.com, which the attacker has rebound to the target’s IP address.
 
The policy XML provided by the attacker in step 3 instructs Flash Player to permit arbitrary socket access to attacker.com. Flash Player permits the socket connections to the target because it does not pin host names to a single IP address. 
 
Flash Player would still be vulnerable to multi-pin attacks  even if it pinned DNS bindings and avoided the standard DNS rebind attack. Flash Player does not retrieve its movies directly from the network.
 
Instead, the browser downloads the movie and spawns Flash Player, transferring the movie’s origin by host name (as set in the "codebase" attribtue of the <object> tag). When the attacker’s movie attempts to open a socket, Flash Player does a second DNS resolution and would pin to the target’s IP address. 

Clickjacking

Clickjacking is an attack that applies the invisible property of style sheets to HTML div tags or iframes in order to transparently overlay malicious content on top of trusted content. By making an iframe or div tag invisible, an attacker can hide malicious content underneath the mouse. Since these tags can also float, they are able to follow the mouse around the web page. When the user attempts to click something on the web page, they will actually click the invisible div tag that was following their mouse around the page. This allows an attacker to trick the user into clicking anything that they want.
 
Within Flash Player 10,0,12,0 and Flash Player 9,0,152,0, Adobe added protections against clickjacking to sensitive Flash Player controls such as the camera and microphone permission dialog box. However, the more general case of using clickjacking to commit click fraud against SWF- or image-based advertisements still remains in the web browser.