[Security] Cross Site Scripting (XSS) in flash files

February 8, 2010 - 12:23 UTC - Tags: flash security xss Recently there has been a lot of fuzz about security problems in flash files. At the recent Blackhat DC 2010 Mike Bailey also discussed this very topic. These problems are not new, but have somehow avoided getting much focus earlier. Input validation and output escaping in flash seem to be ignored.

Cross site scripting(XSS) in flash
A flash file is in itself a small program taking its own inputs from HTML or URLs. It's compiled into a flash specific byte code and runs in the flash plugin in your browser.

When embedding the flash file into an HTML page, the flash developers often allow the flash file to supply variables to control things like target url when the user clicks the flash film (very common in ads). I'll take this as an example. A very common code snippet for this is:

 on (release) {
    getURL (_root.clickTAG, "_blank");
}

This code accepts a parameter called "clickTAG" which is used to control the target url. However there is no input validation. As explained in Adobe's guide to creating secure flash apps in "Script injection into the browser" chapter, if the url (clickTAG in the example above) starts with "javascript:" the javascript following it, will be executed when the user clicks the flash (e.g. the call to getURL is executed).

Now how can this attack be performed, one might ask. The flash file is normally embedded in an HTML, and the attacker can hopefully not alter the HTML in your page (then you have other XSS issues already). But the attacker can link directly to the flash file with the parameters as url parameters:
http://url/to/flash-file.swf?clickTAG=javascript:alert('xss')
Is this really dangerous?
As we see this is a reflected XSS attack, and it also requires the user to actually click the flash to execute the javascript. So the probability might be quite dependent on the contents of the flash. But we can imagine this being used in targeted phishing-attacks. Fake emails with "There is something weird with this ad. Click it and see what happens" or "Check this cool competition (just click the flash banner to get to the competition)" might trick some users. Especially if the fake email appears to come from the organization hosting the flash. Remember that the url in the email will actually be pointing to your domain. So the common anti-phishing education where users are taught not to click links without checking the url, doesn't work here.

Input validation
Fixing the above code is quite easy. Before invoking getURL we have to check that url doesn't start with "javascript:" (or "JAVASCRIPT:", "jAvAScrIpT:" etc.). But this type of blacklisting often proves to have some problems because of unknown other attacks (hint: check "asFunction:"), so it would be better to use a whitelisting approach:

 on (release) {
    if (_root.clickTAG.substring(0,5)== "http:" || _root.clickTAG.substring(0,6)== "https:" || _root.clickTAG.substring(0,1)== "/") {
        getURL (_root.clickTAG, "_blank");
    }
}

The above code above only invokes getURL, if the url starts with "http:", "https:" or "/" (relative url). You might even want to make it more restrictive (e.g. only point to urls on your own domains), to further reduce the risk of use in phishing.

Is this the only way to do XSS in flash?
No, there are a couple of other ways to do it as well. See the resources below, especially slide 20-30 of "Blinded by flash".

Help - I want to learn more
Resources:

Adobe's guide to creating secure flash apps
OWASP Flash Security Project
"Blinded by flash" (slides as pdf) by Prajakta Jagdalen - Blackhat DC 2009
Neat, New, and Ridiculous Flash Hacks by Mike Bailey - Blackhat DC 2010
A Lazy Pen Tester's Guide to Testing Flash Applications