In the course of a pentest I found a Flash movie file (swf) that loads another Flash movie through loadMovie. The HTML is this:

<embed width="388" height="350" src="http://www.domain.com/first_flash.swf?
videoload=http://www.domain.com/videos/second_flash" quality="high" 
pluginspage="http://www.macromedia.com/go/getflashplayer" align="middle" 
play="true" loop="true" scale="showall" wmode="window" devicefont="false" 
bgcolor="#ffffff" name="interior" menu="true" allowfullscreen="false" 
allowscriptaccess="sameDomain" salign="" type="application/x-shockwave-flash">

As you can see, there is the directive allowscriptaccess="sameDomain". Also, if you access the Flash file directly I understand that recent Flash plugins use this setting as default.

In the first_flash.swf, I found this code that loads the second movie:

_root.videourl = _root.videoload + '.swf';

I have tested I can actually change the videoload variable to load swf from other domains. But I can't seem to execute javascript with getURL on a second_flash.swf controlled by me.

So my question is, what can I do to exploit this poor design? How can I show that it is, in fact, dangerous?

  • Does maybe XSS helps with this? Aug 7, 2012 at 21:26
  • That's the objective, but how?
    – chmeee
    Aug 8, 2012 at 15:55

2 Answers 2


Original source -- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership

2.4.1. Abusing Flash’s crossdomain.xml

The same origin policy can often be deemed too restrictive, causing application developers to clamor for the ability for two different domains to work interactively with each other. One of the first popular browser plug-ins to support such cross-domain interaction was Adobe’s Flash. Adobe understood the dangers of allowing arbitrary cross-domain access and implemented a security measure to determine whether Flash would allow for cross-domain interaction. This security measure is implemented via the cross-domain policy file.

Flash’s cross-domain policy file defines the “rules” for cross-domain interaction. The cross-domain policy file is simply an XML file named crossdomain.xml. Here is an example of a crossdomain.xml file:

<?xml version="1.0" encoding="UTF-8" ?>


    <allow-access-from domain="*" /> </cross-domain-policy>

This crossdomain.xml policy file must be hosted on the server that wishes to allow for cross-domain interaction. Before allowing cross-domain interaction, Flash will check for the presence of a cross-domain policy file on the target domain. If no policy file exists, Flash defaults to the restrictive same origin policy and disallows cross-domain interaction. If a crossdomain.xml file exists on the target domain, Flash reads the “rules” contained within the policy file and allows cross-domain interaction based on the established rules. Once again, the entire premise is based on the fact that the cross-domain policy file must be served from the domain that wishes to allow the cross-domain interaction. By default, Flash will check for the presence of a cross-domain policy file named crossdomain.xml in the web application’s web root (http://www.example.com/crossdomain.xml).

Beginning with Flash 7, you can make Flash check for crossdomain.xml in arbitrary locations (not just the root of the web root) when the Flash component invokes loadPolicyFile() with a URL as the parameter (containing the location of crossdomain.xml on the target server).


You can find more information on System.Security.loadPolicyFile() at the following website:


The concept of Flash’s cross-domain policy is based on a few simple premises. A simplified version of the logic is as follows:

The cross-domain policy file must be located in a web-accessible path of the web server to allow for cross-domain access from Flash to that server.

The only way someone can put an arbitrary file into a web-accessible path of the web server is if he has administrative access to the web server.

Therefore, if the web server has a cross-domain policy file in a web-accessible path on the web server, an administrator must have placed it there.

This logic is inherently flawed because many web applications allow users to upload content to the web server. If the application subsequently serves that content under its domain name, that web application has unknowingly put itself at risk because of Flash’s cross-domain abilities. If an attacker is able to upload a crossdomain.xml policy file, the attacker can use an evil Flash applet on her web server to attack the vulnerable application. This evil Flash applet will be able to make cross-domain requests to the vulnerable web application and those requests will be made with the session cookies of any unfortunate users who happen to stumble upon the attacker’s website. To make matters worse, the cross-domain policy file need not have the .xml extension. Flash’s security criteria will honor any file extension.


Adobe Flash allows for the specification of “meta-policies.” These policies define which policy files on the server should be honored. You can find more information on meta-policies at http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html.


Everything here depends on the version of your Flash Player. Here's a list of stuff, which you should try on this .swf file.

Our first guess was Cross Site Scripting so we should try our hand at XSS, especially that we noticed one of the unsafe method: loadMovie.

Cross Site Scripting

There are a few types of unsafe functions. Each of them has different payload:

  • getURL - payload: javascript:alert('XSS')
  • load* (in this case: loadMovie) - payload: asfunction:getURL,javascript:alert('XSS') [asfunction works in this context until release Flash Player 9 r48]
  • TextField.htmlText - payload: <img src='javascript:alert("XSS")//.swf'> [.swf is very important here - other extensions won't bypass the internal filter of the Flash Player].

Cross Site Flashing

our second guess should be XSF. The first flash movie tries to load the second one. When it gain the access to the same part of the sandbox, we are vulnerable to XSF. This means, that we are able to load the external, evil flash file, which can lead to XSS or fake flash-movie (for example: fake flash-form, kind of phishing). Now let's think for awhile when we could get that flaws.

Flash Player 7 or later permits cross-domain scripting only between the same domain. We can load .swf files from different domains, but that files won't be able to exchange data. For more details you should check System.security.allowDomain.

Now let's talk about:


This parameter can be found inside param or embed tag and it decides about the ability to perform outbound URL access from within the SWF file. There are three possible values: - sameDomain: access to communication is allowed when .swf file and the embedding HTML page are in the same domain. - always: the same as sameDomain, but .swf file could also communicate with .swf from the different domain (than it is embed). - never - .swf file can't communicate with any page. Application layer protocol, domain name and port number define the origin. When .swf file gets JavaScript code to execute from the browser, it will be executed within the origin of embedding website. Let's consider two situations [allowScriptAccess = sameDomain]:

  • .swf hosted on A.com is embed in the HTML website on B.com: origin: B.com
  • B.com has an iframe which load .swf file from A.com: origin: A.com

The default value is set to sameDomain. It means that .swf without AllowScriptAccess attribute should be considered as the .swf with the sameDomain property. In 2008 it has been noticed, that sameDomain could lead to Cross Site Request Forgery. I really recommend you to read the blog-post about this (more details - here) and look at the PoC.

You shouldn't forget about Flash Parameter Pollution.

Flash Parameter Pollution

Not every .swf files can load without the original HTML. If the programmer forgot about the sanitization, we could inject global variables into flash:

print '<object type= (...) data="'.$_GET['flash'].'"></object>'

URI: http://example.com/?flash=flash.swf?var=bum

HTML: <object type= (...) data="flash=flash.swf?var=bum"></object>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .