ActionScript.com The Flash/Flex ActionScript Developer Community

Saturday, May 17, 2008

You are here : Article

Home

Tutorials

Forum

Consulting Services

Archives

About Us

Flash (In)Security

Created By Satori Canton, at 4/7/2005 - 34 comments.

Satori has been an internet consultant since 1994. He is an Adobe Flex Champion, specializing in Rich Internet Applications (RIAs) using Flash, Flex and AIR.

Click to view this author's website.

Important Note: The following article discusses issues of web security for the benefit of Flash application developers looking to make secure Flash applications. Most of the material presented is commonly available on the web and known to both the web security community as well as the web hacking community. Where there is new information, I'm being purposefully vague; alerting the reader to the threat and the remedy without actually releasing the exploit. None of these techniques should be used on any server or Flash application that you do not own or have permission to test security upon. If you get busted doing something you shouldn't have, and end up going to the FPMITA Prison, don't send me the hate mail.

As Flash evolves from being a web toy to an interface for Rich Internet Applications, the security issues with Flash are becoming more important. The very term Flash Security is an oxymoron. Anything running on the client-side is inherently insecure. Furthermore (and often more importantly) anything communicating from the client to a server (especially if that server is connected to a database) is under threat and extremely vulnerable.

Decompiling a SWF

The first thing to be aware of is that ANY code you put in your Flash SWF file is readily available to anyone that has access to it. With a free decompiler like Flare or the more robust commercial product ActionScript Viewer, every line of code in your movie is accessible and readable in seconds.

People debate the virtues of having an ActionScript decompiler all the time. But what I'm talking about here isn't stealing someone else's code snippet and claiming it as your own. What I'm talking about is the information contained in your code (things like data server URLs, passwords, Flash Remoting and Communication Server connection strings, etc.). It doesn't matter if you are using Flash Remoting or any other type of middleware (ASP, PHP, ColdFusion, etc.). If you are passing inputs to the server, there are a wide variety of ways to attack it.

Once a hacker knows where and how you are communicating to your server, Flash becomes almost irrelevant. They can attack your server directly with a simple web browser.

SQL Injection

One of the most nefarious, effective and common attacks is known as SQL Injection. In short, SQL Injection is replacing web page inputs (for example username and password) with SQL code that, when evaluated on the server, will actually execute in the database. This could allow a hacker to do anything from gaining unauthorized login to stealing and deleting your entire database.

In a demonstration about a month ago, I was able to show one of my clients how to have their entire database e-mail itself to me (using nothing but a web browser and typing in the URL string). The hack took seconds and swept their most valuable data out from under them. Their database has since been locked down.

What do you do to prevent this? Treat all input as if it were evil. Validate EVERYTHING on the server before passing it to your database. If a field only requires a number as an input, then don't allow any other characters other than a number. If you require numbers and letters, then only allow numbers and letters. If someone needs to send you an e-mail address, then only allow numbers letters and the symbols @, - and dot (.), AND HTML ENCODE those symbols before sending them to the database.

Also, turn off SQL mail if your server supports it. Never anonymously connect to your database as the system administrator (sa). Set up a specific roll for your Flash application to use that only allows access to the procedures in the database that you need for that application.

Finally, do not allow your database to display errors to the user. Informative errors on a web page help developers track down bugs. But they can also help hackers discover every part of your database. Create a custom error page (even for pages that are only intended to be read by Flash only) and tell your middleware to ignore errors and resume the next line of code.

Cross Site Scripting (XSS)

Another attack, known as XSS or Cross Site Scripting is common in JavaScript but there is a way to use the same technique in Flash. XSS is sending people a corrupted link to a web page. The link itself makes a JavaScript hit to read the data stored in the cookie for that site and then submit that data to the destination page. The best example of this would be to send someone a link to their web-based e-mail account (i.e. Hotmail, Yahoo, GMail). Many times users of web-based e-mail accounts will click the option to have their browser log them in automatically. The browser can do this by storing the username and password in a cookie. In an XSS attack, the hacker could gain access to the data in the cookie and there by have access to your e-mail account. Once they have the e-mail account, they can get into anything attached to that e-mail account. Go to PayPal (or the person's bank if they have e-mail from them in their account). The user name is the e-mail address. Try their e-mail password and you might get in. If not, tell PayPal that you forgot your password and have them e-mail it to you!

Because Flash's client-side shared objects use a security paradigm similar to JavaScript cookies, it is possible (but a little more difficult) to use a similar type of attack in a Flash based RIA to get the data from the shared object. I haven't heard of this actually happening in the wild. But after tinkering a little, I have seen it happen. To accomplish this, the application has to have a way to submit an HTML link into it (again like an e-mail program would). You would have to have some knowledge of the inner workings of the SWF (which is not a problem if you decompile it). From there it's pretty simple to have Flash send you almost any data you wanted.

Conclusion

If you're just building little Flash toys, security may not be much of an issue (if at all). But if you are doing any kind of client-server communications or if you are storing data (any kind of data) on the client or especially in the SWF itself, you'll need to be aware of the threats and dangers involved.

A full discussion of network security is beyond the scope of this article. But if I've wetted your appetite and you want to learn more about web security in general, there are plenty of tutorials on how to prevent both SQL Injection and XSS to be found on the web. Even if you are not a Windows developer, I would also recommend the book "Writing Secure Code, Second Edition" from Microsoft Press. It has volumes of information about network security issues, including many issues that apply to web developers.

del.icio.us || Digg It || Technorati