Cross-site scripting (XSS) vulnerability

Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject client-side script. XSS stands for many of the attack we see on the Web today. Attackers find some kind of a creative way to inject script into web pages, which than allow them to expose the user to many security risks, for instance attackers can do the following:

1. Account theft - Attackers can grab cookie information, which can lead to account hijacking since many cookies holds account information.
2. Changing content on a page - Misleading user to re-enter their information on a phony site, place incorrect content or read user’s cookies.

The idea is to involve more than one site, and that’s where the name (Cross-site) came from, a second site injects a script and can do anything it wants with the page.

Vulnerability in Flex applications

Flash Player is not vulnerable to cross scripting directly since the byte-code get compiled through the Virtual Machine (VM), however Flash is often used on a page that includes other scripts and your application may interact with other Web pages elements and that can open a security hole since Web page that generate content dynamically without filtering the results first. Attackers can exploit your application and create XSS.

Cross-Scripting attack to a WebPage from Flex

In this example the user entered their name and the information is passed to a Javascript function. Take a look at the example below.

Add the Javascript function to index.template.html in the header tag. The index.template.html is used by FlashBuilder to generate your HTML page so adding this script will ensure you always have the script once you clean your project. Compile the example and you will see the figure below.



After the user submits the form the name display on the Web page, just as intended, however take a look what happens once the user insert the following code instead of the name:

As you can see we inserted Javascript code and it was passed to the HTML page and executed by the browser. Displaying an alert box is pretty harmless. However, having the ability to add the script tag allow the attacker the ability to inject a script for instance:

Or a redirect:

The malicious script can do anything it wants with the web page that allows executing the javascript code.

Malicious data injection

In cases where a Web Page have permissions to reading and writing from and to a Web Page an attacker can abuse these and rewrite the a web page or redirect users from the Web Page to a phishing site, this type of a attack is know as malicious data injection attack or Script injection.

The attacker can inject data and create a cross-site scripting (XSS) attack. Coding in ActionScript and using APIs such as ExternalInterface, navigateToURL or getURL. The attacker can than redirect the URL and even post a JavaScript code, which would capture the user’s cookies with personal information.

Let’s say we need a script to retrieve a parameter that was passed through the URL into my Flex application. As you know you can pass variables using FlashVar and than use the following syntax in Flex 4 To read the parameter:

FlexGlobals.topLevelApplication.parameters.name

However in case you want to pass the parameters through the URL you need to call the SWF directly like so:

MyApp.swf?name=Elad

My code allows me to read the parameter from the URL without calling the SWF directly.

Here is how it works. I am registering a callback Javascript function called getParams and once the user click on a button I am calling the Javascript method getURLString, which retrieve the URL parameter and pass it back to the callback.

Take a look at the JavaScript code, which include the two methods getURLString and sendInfoToFlexApp. Once our Flex application calls getURLString the URL parameter is retrieve and sendInfoToFlexApp method checks the type of navigator (Explorer or other) to access the Flex application element and than send the information to the call back method in Flex as well as call an element on the page.

Note: instead of using the application name I am using ${application}, since this code is placed inside of html-template/index.template.html, which will replace the token with the application name once we compile.

Compile and run the application. Don’t forget to pass a parameter in the URL: App.html?name=Elad

And once you click the button the URL parameter is retrieved and Flex opens an alert popup to display the name.

Although it looks pretty harmless and common, take a look what happens when instead of ?name=Elad I pass the following parameter: ?name=%3Cscript%3Ealert('Elad')%3C/script%3E

Cross-site scripting through navigation URLs

Attacking browser navigation URLs is a popular attack. Similar to the example I showed you at "Malicious data injection" section, attackers can inject data through URL. In addition to passing data through FlashVars it's common to use deep linking to change the application state. The application takes params through the URL and than create a link on the application.

History Management vulnerability in Flex 3

The same type of cross-site scripting we just showed you were found in the History Management handled by historyFrame.html in Flex 3. The vulnerability occurs in code used by the History Management feature. In case you use Flex 3 and use the History management features you need to upgrade to at least Flex 3.0.2 SDK Update or just replace the HTML files from Flex 3.02.

How to avoid Cross-Scripting attack

The way to avoid must of cross-scripting attacks is to sufficiently sanitize user-supplied data, what it mean is that it’s a good practice to apply the same best practices as old-fashioned web application and to filter the data that user enters to insure that the user entered a proper format and contains only expected data.

To avoid this type of vulnerability you can add a code to your Flex/Flash application that will stripe HTML tags, tag attributes, values, Javascript, CSS, HTML and URL.

There are two approaches. You can take the whitelist or blacklist approach in regards to validating the data. Whitelist is preferred, however whitelisting isn’t always possible so blacklisting can be used.

Find HTML tags In our first example you can adjust the clickHandler method and escape HTML and script tags, you can be more specific elements:

Use RegExp to avoid attacks

The previous example is great, however there are cases where the attacker may try to camouflage strings with Hex equivalents. For instance technique. Take a look at the following example: I am using the RegExpValidator component and pass the RegExp "((\%3C)|<). In case there is no match you’ll get: “field is invalid”.

You can insert all the RegExp and see if you get zero results, which means that the expression was present.

To read more see Symantec article: http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-site-scripting-attacks

Update Flash Player and SDK often

Updating Flash Player and SDK. Adobe is constantly working to fight attackers. For instance during the upgrade to Flex SDK 3.4 Adobe have solved an issues regarding ticket CVE-2009-1879, which took care of Cross-site scripting (XSS) vulnerability in the index.template.html in SDK 3.3. When the installed Flash version was older than a specified requiredMajorVersion value it allowed the remote attackers to inject arbitrary web script or HTML via the query string.

Check OWASP Flash Security Project that includes numerous resources on security:

Follow @EladElrom

Read more from Elad Elrom.