I was checking the stats of the site sometime ago and found that onrelease.org was pretty high on my referrer list for some reason. Interested, I went to the site to found out why. It turns out that Aral Balkan had blogged a comment on my blog entry about security problems in Flash. I have some follow-ups about the issue in my own blog as well, but since there was discussion on another site as wll, I thought I'll just post about it again as a new entry. Quoting Aral, he comments that "The moral of the story is one that we already know: Never place any sensitive information on the client and *always* validate and authenticate every call on the server before acting upon it. " I agree completely. But the big problem with Flash still is the client side security. I contend that the more complex the client application gets the more difficult it is to validate every application state and value change on the server. Think about a car game for example: if you programmatically change your car to make it a bit more maneuverable and then drive record lap times with it, how would you validate it? You would have to send every key press and the time it was pressed to the server to validate the values against the same physics engine that is supposed to be on the client (this kind of cheating happens to be a real world example). Or a tank game, where you programmatically change your tank turret to always point to the direction of the opponent (same concept as in Electroserver's demo tank game). There's nothing - or very little - on the server side you can do to prevent it.
Client side security is always a problem and you can never make it completely secure, but with Flash it's just so easy and simple that it makes the life of a multiplayer Flash game developer so much harder. The idea is to make security good enough and make it difficult enough for others to hack it that they won't even bother to try. I don't know any other environment that would be as vulnerable to client side attacks than Flash. In my opinion, Flash needs two things: an option to prevent host swfs to change the run-time behavior of a child swf and a better file format more suitable for obfuscating the code. These two things would go a long way towards addressing the security problems in Flash.
Is there any way to control flash files content stored in local files against code tricks? If not directly in swf files so maybe in JAVA calling swf files? Really anybody can change local *.swf and make what he/she wants? Or is there only way to control the data sent back from local host to server (but it is very primitive and doesn't secure anything at all)?
The trick is for some of us so obvious that even ridicilous. I would suggest some crc check or more sofisticatated content check. Does anybody know any way to do that now?
Posted by: master_of_flashes at August 17, 2004 07:26 AMNo, currently there's no way to prevent localhost from modifying your swf at runtime. I'm suggesting two ways to improve the security in the end of my post, change the Flash player to prevent it and make it easier to obfuscate the Flash code. There's really nothing that Java can do to help the situation. You cannot even run the modern versions of Flash format inside a Java app. Crc check wouldn't work because you are dynamically changing the behaviour of a Flash app at runtime. Content check then, well it depends, but it would still be better to just change the Flash player so that the same domain security would apply to localhost as well.
Good blog with interesing information!
Posted by: Sofia at September 2, 2005 12:44 PM