I work for an online casino. We have a product where our software suppliers give us a flash version of the casino, hosted by them in an iframe on our site.

We need to get close-to-real-time data from the software provider, but due to the massive amount of data involved we have a significant lag between when, say, a user wins a bet, and when the data is eventually routed to us.

Even with extremely high transfer speeds this can take a minute or so - too slow for us to react and perhaps, show the player a "congratulations" message.

I realized the other day that with LocalConnection, the flash casino in the iframe could transmit data in real time to a flash movie in my page - thereby speeding up the process, and cross domain to boot!

It would be trivial for the casino to broadcast certain events - big wins, low credits etc, and then we would be able to react much faster.

Where this plan will falter is security.

I know LocalConnection uses a unique ID to get flash to flash communicatuions, and with the unique ID generated on the server, we would be able to ensure that only the two flash movies would be communicating, and it would be one-way communication - the casino would send out data, but not receive.

Aside from just that single unique ID, what is the security on LocalConnection like? Is there a way to sniff the traffic? Is there a way to falsify the traffic?

As the flash casino is just a thin-client for the actual server-based software, I do not think there would be any sensitive info exposed, and if the flash casino only broadcasts specific data, which our suppliers could specify, it seems like a good way to do it.

Are there any down-sides or potential problems, especially security-based, that anyone has heard about?

Since my last reply in flash was sent to purgatory without any explanation to me...

Why derail someone else's thread for it? That right there is worth a ban.

You know I am the mod here in the flash forum. You could have sent a PM or told me to check purgatory when you weren't getting a reply. The guy you refer to was a product shill. I was trying to remove it quietly since you replied to such an obvious seo hack. But fine. You replied to link spam. Sorry, I will point it out much more loudly next time.

To answer the question Scudsucker, there is a port interaction between the two swf's which I suppose could be sniffed, which would be the easiest way, with a bit of spoofing DNS or HOST file after port surfing the local machine, assuming you've managed a root kit and then mimic a swf running from your domain and then hoping the two swfs are communicating anything of importance.... I am not going to say more cause I don't advocate any type of behavior like that.

As well, the port is used to share memory blocks in ram between two swfs. The memory blocks themselves are probably AMF format, which is flash object binary, which would be easy to parse if you can do a buffer overflow within 5 seconds to keep flash from expiring the ram allocation.

For a casino, I am gonna say there is simply to many variables to know for certain what level of security you're looking at and what type of hacks you're liable to run into.

There'd be a lot simpler ways to attack a site, but no one wants to be holding the oh fudge stick when the candyman comes to town. In a high security environment i would narrow down your communication channels to as few as possible and keep them on https. You could do a dedicated https message bounce between swfs on a LAMP instance to bypass your slow large data on the servers, just for user notification.

which I suppose could be sniffed, which would be the easiest way, with a bit of spoofing DNS or HOST file after port surfing the local machine, assuming you've managed a root kit and then mimic a swf running from your domain and then hoping the two swfs are communicating anything of importance

We already have users attempting such things (hacking), but the flash casino is the very definition of "thin client", so no information that cannot be sniffed anyway is in the flash part.*

It is trivial to listen in to the communication between the flash & the actual casino running on the server, using Charles or similar (but not cross domain from within a browser.)

The reason why I thought of flash LocalConnection is that it is an easy to implement way to share what is essentially "public" data. Our software suppliers are resistant to change, and with the "https message bounce" method you suggest I will meet resistence due to the large volume of data that is already sent.

LocalConnection seems to me to provide an interface to the (limited) data in the flash front-end, essentially allowing me to extend the GUI, with the very important feature that it is all client-side, no expensive servers required.

Thanks for your analysis - the outcome, is yes, it is not really secure, but no less secure than the current setup.

• One amusing thing when people say they are having problems, is to get them to send a fullscreen screenshot and examine the desktop shortcut icons... from what is on the desktop it is often pretty easy to assess if there is a problem or if the problem was forced

Remember though that any method declared in the client context (it defaults to "this") of the local connection object can be called. Meaning if a sniffer decompiles your swf, he can start to arbitrarily call methods in scope, not just the one you intended to use with public content. So sandbox your local connection in a class, keeps its methods dumb, and declare a client scope on the local connection object.

Thanks for the heads-up