Lot of talk about security with FCS

Anybody on the Figgyleaf Flashcomm mailing list has heard these stories before and especially now of how some connection lines are getting jacked, or even the whole applicaton! Poor Peldi has had his whole swf taken into a frame of another site and used to the hackers discretion. Why does this happen? Who's responsiblity is it to secure the FCS apps? What can we do to not have this happen?

Read on for more on my thoughts on the security of FCS.

Well there is a mighty force brewing in the FCS developing world right now. All kinds of ideas of how to "get the hackers" and whatnot if they try and come to take your app away to their own world. This is all cool, as there are tons of ideas out there of how to check where the swf is being read from, the html file, and where to direct them if they aren't in the right place. It's cool to see a community come together on something.

So what's the problem anyways? Well, to get an answer for that you have to take a look at the security for FCS and how it can be manipulated. How can you protect your apps straight out of the box? (or straight after the DL from MM's site). By default, there is no security set up for FCS, you have to change up some of the files a bit yourself (which is quite normal) There is one way to secure things right away. That would be to go into the vHost.xml file and change up the Allow tag down near the bottom of the file. There is also one in the adaptor.xml file, but for most who don't have their own server, the adaptor.xml file will not be available for you to change.

There's a server side script that can be created for this type of thing too if you can't set the vhost or adaptor file to limit domains, and that is to get the referrer of the app, but this is a poor way to implement security in a Flashcom app as it can be faked by just writing the name of the domain as the name of the directory or file, and it can be got around just a little too easily for my liking.

BUT, as we have seen with Peldi's app, neither of the above help. What happened with him is that the hackers took his swf, not to put on their site, but to just link to in their own frame and used his app freely. That's easy! So, even if Peldi had his security up on his app, which supposedly he did, it doesn't make a dif in this case as the file is literally still on his own site... and the referrer is pointing to his site.

So what is a true fix, and good security? Well of course implementing the above works well for most situations like when somebody rips off your connection string (which is simple with ASV), but how about when they want your whole app, and not just the connection string? This seems so weird though... maybe put a big logo on there? Welcome to MY (substitute your name or site name) CHAT APP.

First off use a DB, and create a proper logon sequence to the page. Make sure the user is a registered user of your app, then let them connect up to the swf. Of course if somebody registers for your app and they make it in and then steal your connection string.... well you may be hooped but not if you combine the above with some proper server side script and remoting. So far, the best combination I have found is to make sure you pass over the username and password to the FCS server (over https), and have remoting (if you have it) on there check a DB if the user is a registered user. This can all be done in the server side of the FCS app asc file. If they aren't a registered user, you can tell them so (maybe they got the PW wrong) At the same time, you can keep a record of how many times they messed up with logging in, and lock them out, but that's getting a bit indepth for this post.

What do you do when a registered user rips off your app then?? setting it up so that anybody can log into the app with the registered user's username.. Well, then it's a matter of making sure the file is not being put in a frame on somebody elses site. There are multiple ways to do this depending on the server side language you are using.

I'll try to post more on this soon, but what a headache this is for all FCS developers. It sucks that there isn't an easy way to protect our apps, but the technology is young and I'm sure MM will think of something to combat these new style of hackers. If anybody has more ideas, or things that worked for them, I'd be glad to hear about them along with the rest of the FCS dev community I think.

Posted by Graeme at January 5, 2004 10:35 AM