|
Now that more and more people are jumping onto the Macromedia Flash application
bandwagon I'm starting to see a growing number of questions about
security and Macromedia Flash. In particular, developers are often
unsure if Macromedia Flash applications can have the same level of security
as a well-designed HTML-based application. The answer to that
question is most definitely yes, if you design your application
properly.
Of SWFs and ostriches
The first thing to understand about Macromedia Flash is that,
from a security standpoint, it's no different from HTML and JavaScript
- anyone can read the source. While SWFs aren't human readable
like HTML and JavaScript, there are numerous tools out there for
taking a SWF and extracting all of its assets, including ActionScript.
Because of this fact you should never hard code sensitive data
inside of your SWF; doing so would be the security equivalent
of putting your head in the sand like an ostrich and assuming
that because you can't see anyone, they can't see you.
You probably realize that this means that all of the data that
your SWFs need must be retrieved from a server. Luckily you can
use the exact same methods that standard web applications use
to keep those data exchanges secure.
Macromedia Flash & SSL
The standard method for ensuring secure connections in web apps
is to work from behind a special type of web server; a HTTPS server.
This is just a standard HTTP server that has its communications
encrypted with SSL (secure socket layer) technology.
When you use POST to send data from Macromedia Flash to the server, the
Macromedia Flash plug-in utilizes the browsers POST capabilities rather than
handling it directly. This is done so that if it happens that
the SWF is communicating with a HTTPS server the data will be
encrypted before it is sent. What this means to you, as a developer,
is that you just need to take the same precautions with a potentially
sensitive Macromedia Flash application as you would with a sensitive HTML
app - place it on an HTTPS server. This way, not only will the
data you send to the server stay secure, but also the little lock
icon at the bottom of the browser will be locked, indicating to
your users that your application is secure.
Crypto Hash Boulevard (It's one way)
Sometimes it's simply not possible to set up or get your hands
on a HTTPS server. In those situations you can at least keep some
of your data secure by using what is known as a cryptographic
hash function. A crypto hash function is a function that given
input produces a unique output that can not be used to determine
the input value. That is to say, a crypto hash function is one
way—you can get the output from the input but you can't determine
the input just by looking at the output.
Crypto hash functions are useful when the user knows their password,
and you have their password stored on the server, but you don't
want to have to send the password as plain text across the Internet.
The way you use a crypto hash function to do this is as follows:
- First your SWF contacts the server and asks for a random string
(let's call it S). Before the server sends S to your SWF it
records its value.
- The SWF then concatenates S with the password the user inputted
and feeds the result through a crypto hash algorithm (let's
call the result A).
- Now the SWF sends A to the server. The server then finds the
value for S that it sent to the SWF and concatenates it with
the users password that it retrieves from the database. The
server then runs the result through the same crypto hash function
that the client used. (Let's call the result B).
- Finally, if A and B match, the server knows that the password
was correct. The actual password (or anything that could be
used to find the password) was never sent across the net.
There are a number of these types of algorithms out there, but
the two most popular are known as MD5 and SHA1 (catchy names,
eh?). SHA1 is generally considered to be the more secure of the
two, because its output is longer than that of MD5 (the longer
the output the harder it is to try to crack). You can download
an implementation of SHA1 for ActionScript from my personal website:
www.waxpraxis.org.
Other security concerns
In addition to concerns about keeping Macromedia Flash's data
secure, I have also seen a number of e-mail messages and posts
worried about the new local file system, camera, and microphone
capabilities of Macromedia Flash. The good news is that there
is nothing to worry about (I've personally tried to break it many,
many times and have yet to make a dent).
All of these features are secured per domain in a method that
is even more secure than browser cookies! That is, the user has
to set their options for who can use access their webcam and mic,
as well as how much information can be stored on their hard drive
on a per domain basis. One domain can not read information stored
by another, period.
Also, in order to prevent cross-site attacks, a SWF is limited
to loading data from the domain where the SWF itself is stored.
A movie on www.macromedia.com can load information from foo.macromedia.com
but not from www.nastyhackerperson.com.
Macromedia Flash and JS
One issue brought up recently has to do with the fact that Macromedia Flash
can call JavaScript by using getURL like this:
getURL("javascript:alert('hello!')");
Because of this, any site that allows users to display their
own SWFs is open to a having its users cookies stolen. The fact
of the matter is that nothing should be allowed to be displayed
on your site until it has been properly "sanitized",
and yes, that does include SWFs (even ones that are just linked
in).
Conclusion
Hopefully this article has given you a leg up in understanding
how to work with Macromedia Flash securely. For more information
on Macromedia Flash and security, make sure you read the Macromedia
Flash Security white paper (498K in PDF format).
| 
