Tag Archives: crossdomain.xml

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="http://www.whitehatsec.com" />
<embed src="swf/banner.swf" flashvars="img=image1.jpg&amp;link=http://www.whitehatsec.com" />

Attackers link to SWF:



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:

http://www.example.com/swf/nameTag.swf?name=<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.



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
Guya.net – Flash Bug in Internet Explorer Security Model
OWASP Flash Security Project



Jason Calvert @mystech7
Application Security Engineer
WhiteHat Security, Inc.

Flash + 307 Redirect = Game Over

A vulnerability for Ruby on Rails was recently patched [http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails].
Why the Patch Was Necessary
The default CSRF prevention built into RAILS has two components: (1) a custom HTTP Header, and (2) a CSRF token in the post body. The default was designed so that only one, rather than both, of the components was required in a request. Modern browser security typically makes this a fairly secure method, because JavaScript cannot create custom HTTP Headers and then have them sent across domains. However, a researcher from Google found a way to exploit this issue by using “certain combinations of browser plugins and HTTP redirects.” Because of this discovery, the new patch for Ruby on Rails now requires both components to be in the request, preventing exploitation.
How the Vulnerability Bypassed the Default CSRF Security
A hidden flash file on a website automatically sent the following request:
Flash allowed the site where the file was running to specify POST data and additional headers. But before sending the request, Flash checked the site’s crossdomain.xml file. Attackers then set up their cross domain.xml files as follows:
<?xml version=”1.0″ encoding=”UTF-8″?>
<allow-access-from domain=”*”/>
<allow-http-request-headers-from domain=”*” headers=”*”/>
Based on this, the Flash file understood that it then had permission to send additional header information with its request, and proceeded to send the request with extra headers to
The attacker site returned a 307 redirect. The 307 is like a 302 redirect, but also allows the forwarding of POST data. The Flash application, realizing that the data was going to another Web server, attempted to retrieve the crossdomain.xml file for www.victim.com. Unfortunately, it appears that in certain circumstances, Flash will IGNORE the crossdomain.xml file for victim.com, and rely instead on the original crossdomain.xml file at www.attacker.com. After a confirmation message that would confuse most users, the Flash application sent a new request:
Host: www.victim.com
X-Header: test=data;
Cookie: abc=123
Content-Length: 9
We see here that the POST request was sent to www.victim.com, along with the additional headers and the POST body. This clearly illustrates that Web server frameworks can no longer rely solely on the implied security of additional HTTP Request Headers to prevent CSRF.
Breakdown of the Vulnerability
Mac – Flash Player 10,2,154,12Chrome 9.0.597.94 302 Redirect GET Request, with headers
Chrome 9.0.597.94 307 Redirect Not Sent
Safari 5.0.3 (6533.19.4) 302 Redirect GET Request, with headers
Safari 5.0.3 (6533.19.4) 307 Redirect POST Request, with headers (No Confirmation)
FireFox 3.6.10 302 Redirect GET Request, no headers
FireFox 3.6.10 307 Redirect POST Request, with headers
FireFox 4 beta 8 no bueno
Windows XP – Flash Player
FireFox 3.6.10 302 Redirect GET Request, no headers
FireFox 3.6.10 307 Redirect POST Request, with headers
IE 7 no bueno
IE 8 no bueno