RedTeam

As I’ve stumbled across this phenomenon more than once in the last time during work, I’d like to write a little bit on Flash, how to pass parameters to it and why this is important from a security perspective.
Flash applications (you know, those pesky little buggers ending in .swf that are always crashing your browser ;)) are normally embedded in web pages with the HTML <object> (for IE) and <embed> (for Mozilla etc.) tags. This may look like this:

<object width="550" height="400">
  <param name="movie" value="somefilename.swf">
  <embed src="somefilename.swf" width="550" height="400">
  </embed>
</object>

This is all well and good, but sometimes, developers want a little bit of flexibility. Lets say I want to display some user specific content, like the user’s name in my Flash app. And while I’m at it, why not load some more user data from an XML file? So how can I dynamically change what my Flash app is howing and what file it loads?

This is where FlashVars come into play as one convenient method to achieve this (there are more, see this technote).

FlashVars look more or less the same as HTTP GET parameters and get imported into the top level of a Flash movie. The syntax for <object> is to add it as a <param> tag:

<param
  name=FlashVars
  value="username=patrick
         &userdata=http://www.example.com/udata/patrick.xml"
>

For <embed>, add it as an attribute:

<embed
  src="myapp.swf"
  FlashVars="username=patrick
             &userdata=http://www.example.com/udata/patrick.xml"
></embed>

The variables will get imported and I can use them in my Flash movie. Great, isn’t it? Well, there’s one more thing, which made me write the whole blog post: FlashVars can also be passed directly to the Flash movie, without adding the FlashVars parameter:

http://www.example.com/myapp.swf
  ?username=patrick
  &userdata=http://www.example.com/udata/patrick.xml

You may see where this is going already. The whole point of the story is: These variables almost never get checked or sanitised before being used in the Flash file. With many Flash files, this opens up a whole lot of attack vectors. It is of course a client side attack, because I have to make a user click on a manipulated link.

One of the worst things (security wise) people do is to load external URLs with this technique, like in the example above. Normally, these URLs get loaded internally with the getURL() Actionscript function. Did you know that this function also takes javascript: URI schemes? This means Cross Site Scripting in your Flash movie:

http://www.example.com/myapp.swf
  ?username=patrick
  &userdata=javascript:alert('RedTeam')

By loading external data without verifying it first, you make yourself (or more precisely, your users) also vulnerable to potential exploits in the Flash Player itself. CVE-2007-3456 describes a Flash Player exploit with a manipulated FLV file. This can lead to a complete compromise of the user’s system.

There are of course a lot more possibilities, depending on what problems people are trying to solve with FlashVars.

So, to make a long story short, FlashVars can be easily manipulated and need to be treated like every other user input. Never use them in your Flash application without first checking them like you check your HTTP GET or POST parameters.