True Stories of the TRC-Web Application Security

Vulnerabilities in a Flash


Flash Player-related vulnerabilities currently account for approximately 14% of all Web application vulnerabilities discovered by WhiteHat Security. This statistic is surprisingly high considering that HTTP Archive reports 47% of Web applications are currently using Flash technology.

Flash Media Player is an effective method for delivering stylish vector graphics across multiple platforms to enrich a Web user’s experience. When properly designed, Flash makes a website visit interactive and fun. Unfortunately, Flash can also introduce vulnerabilities to an otherwise safe application. Many Flash developers are primarily designers who may have some programming experience, but little – if any – knowledge about Web security.

Flash Player itself has many security restrictions and policies, but users often misunderstand them – or even purposely disabled them to get a particular feature to “work.” Among many Flash designers, there’s also a common misconception that the Flash framework will provide all the protection their applications need.

One of the most frequent comments I get about Flash vulnerabilities is, “Doesn’t my cross-domain policy file protect me from that problem?” Well, the cross-domain policy file does prevent cross-domain data loading for execution; but it is a unidirectional permission that the server hosting the data file grants. The permission does not come from the Flash file. Some people may find the cross-domain policy file to be “backwards” compared to what they expect, and in many attack scenarios the Flash file will first seek permission from the attacker’s domain before initiating the attack.

Flash Player has an in-depth security sandbox model based on the domain where the Flash file is embedded, and I will discuss the scenarios for when a sandbox policy applies and how that policy can be bridged or bypassed – but in a later blog post. In this post I’m going to focus on the simplest and most prevalent method used today on the Web to exploit Flash files – unsanitized FlashVars.


Flash Player supports several methods to declare variables that are to be used in the resulting content. The two most common techniques are: (1) to declare FlashVars in a related javascript block,  or (2) via the param tag within an embed. A third, and sometimes overlooked, method to declare variables is by directly referencing them in a URL query string. Many Flash designers build their projects based primarily on flexibility in order to allow greater customization and wider distribution, but these “features” often allow attackers to make their own customizations – and then exploit the  application.

Typical banner ad with FlashVars to specify remote image and link:


<param name="movie" value="swf/banner.swf" />

<param name="img" value="image1.jpg" />

<param name="link" value="" />

<embed src="swf/banner.swf" flashvars="img=image1.jpg&amp;link=" />


Attackers link to SWF:'Session%20Information%20Sent%20to%20Hacker');//


FlashVars with HTML Support

If a Flash file is compiled for HTML support for a given textbox, then an attacker can inject a limited subset of HTML characters to achieve remote code execution. Flash framework supports two main HTML tags that are of interest to an attacker: ANCHOR and IMAGE. A simple SWF file that reflects user input can be used to execute malicious javascript when a user clicks on the file.

Attackers NameTag:<a href="javascript:confirm(1)">Haxor</a>


Server Filter Bypass

With the exception of Internet Explorer, Flash Player will evaluate a query string behind a hash character in all browsers. When a URL query string is placed behind a hash character the browser will not forward the query string with the request for the Flash file, thus allowing an attacker to bypass any attempt at server filtering.,+Inc.


Internet Explorer Sandbox Bypass

When directly rendering a Flash file in Internet Explorer the browser will first construct an encapsulating document in the DOM to embed the Flash file. The browser will then put in place a security restriction so that the related content will have no access to the related DOM information of the current domain. As in many Microsoft programs, this was a brilliant concept, but the QA performed was inadequate to ensure that it became an effective security measure. So the fact is, if a Flash file containing malicious javascript is reloaded, it will immediately bridge the security control and give an attacker access to the DOM. The victim clicks once, which initiates the reload; then, thinking nothing has happened, clicks the second time – and gets owned.



A recent Flash 0-day that allowed an attacker to submit arbitrary HTTP headers to an application was the result of an unhandled 307 redirection from a domain controlled by an attacker. Flash Player has always had limitations handling HTTP responses if it receives anything other than a 200 OK. The problem stems from lack of insight into how a given HTTP request is handled by the Web browser. Firefox 4 contains a new API that hopes to remediate this issue by providing additional insight for browser plugins. If a Flash file utilizes an external configuration file an attacker can bypass any attempt to restrict data loading from a given domain if the domain also contains an open redirection. The Flash file will verify that the initial request is for a trusted domain, but will load the malicious configuration file residing on the attacker’s domain.


Proof of Concept

The following video demonstrates the common issue of Flash files targeting external XML configurations via FlashVars without properly validating the XML file that resides on a trusted domain. Camtasia Studio’s popular presentation software was used to produce the video, which shows the vulnerabilities present in Camtasia’s own ExpressShow SWF files. The developer of the files, Techsmith, has addressed this issue with a patch that must be manually applied (available via Techsmith Security Bulletin 5). The patch restricts generated Flash files to loading XML configurations that reside on the same domain as the Flash file.




HTTP Archive – Flash Bug in Internet Explorer Security Model

OWASP Flash Security Project



Jason Calvert @mystech7

Application Security Engineer

WhiteHat Security, Inc.

Tags: Content Spoofing, crossdomain.xml, exploit, Flash, XSS