Comments: Flash (in)security

I believe you are misinterpreting how Flash security is supposed to work.

The Flash Player does try to keep content from different domains separate; for example, you can't see the ActionScript variables in a SWF that you loadMovie() from another domain. This guards only against server-based attacks: a movie from domain A can't insert itself into the conversation going on between a user and domain B. This is beneficial both to the user and to innocent domains.

One thing the Flash Player does NOT do is try to prevent client-based attacks. That's because this is impossible to do, and any illusion of such security would be a false promise. If someone knows how to download a SWF and modify it, or run it from their local machine, nothing can stop them. If someone knows how to hack the Flash Player, nothing can stop them. If someone knows how to write a native application that looks marginally like the Flash Player to a server, but really isn't, nothing can stop that either.

This is why all serious Internet security must be enforced on the server. It is always a mistake to trust a client. Anyone can come at your server with any client they wish. If your SWF is checking a password in ActionScript, and then tranmitting a wire transfer order to your bank without the password, and the server is trusting that the SWF has already checked the password, you are making a bad mistake.

Most people who write games aren't very serious about security, so games are often easy to hack. It would be much more surprising and dismaying to find an e-commerce site that doesn't enforce security on the server.

Posted by Deneb Meketa at February 10, 2004 12:54 PM

Thank you for your comments Deneb. I believe I'm not misinterpreting how Flash security works, on the contrary I believe I understand it fairly well. You don't need to download the swf, you already have it in your browser cache, and every kid who knows anything about the web knows where the cached files are stored. If you don't, just let the computer find the file from your hard disk. Neither you need to have a hacked version of the Flash player nor have the swf that you are attacking to run on your localhost. It's enough that you run a host swf on localhost that loads the target swf from a valid web server.

I KNOW that the security must be enforced on the server. The question is, does the rest of the world know? My experience is that they don't or they don't care. Would you like me to give some examples of that? The server side security was hardly my point though.

The point and the problem I have with Flash is that you can change the program behavior run-time and that it is extremely simple to do that. While the same would be technically possible if you hacked your Java virtual machine or ran Javascript in your own browser engine, it is just much more difficult. With html pages the idea is to keep the client really dum so you can validate simple value changes on the server. If you need to do complex processing on the client it makes no sense to validate every single value change on the server anymore, so you tend to rely on the built-in security mechanisms of the client engine (OS, VM etc.) being good enough, as is the case with Java as a rich client. Now with Flash you'll get a rich client without any security at all.

Posted by Alphageek at February 13, 2004 01:44 PM

Hi there.

Posted by jon huron at January 1, 2005 04:21 AM

You website is very good!

Posted by Irina at January 3, 2005 10:45 PM

:) Thank you!

Posted by Alexandra at January 10, 2005 12:12 AM

first, i want to say" beautiful blog"

second, do you understand the flash security very well?

Posted by Richard Truman at July 6, 2006 07:51 PM
Post a comment









Remember personal info?