Taking the connector out does rule out one way in, but in to what? Not much.. and you can have that same way in with the right tools. If the client asks for it specifically, of course, remove it.
Security is a server-side issue, plain and simple. Flash has the same security implications as html and _javascript_, it just requires different tools to poke at. Anything you do on the client side is obscurity, not security, because the user has access to perfect information for all client-side information (the entire SWF, cookies, local shared objects, the containing HTML, and any other network traffic whether through HTTPS or otherwise).
For high scores, logins help, but you can still give a legitimate login but a fake score. The only way it's rock solid is if the code never travels to the user's machine. For example, if you were implementing a chess game, you simply verify all the moves at the server, and have all the timestamps generated there as well. For an arcade style game, that's not feasible, and there's just not much you can do beyond obscuring what's going on -- or, as I said before, you can use statistics to weed out probable abuse. It's the same problem as any spam.
Banking is not a big deal at all -- the server controls everything. You can't transfer money that the server doesn't have a record of. Though you definitely want to do your calls through https :)
-bob
On Jan 8, 2006, at 5:09 PM, Rob Bateman wrote: While taking the connector out doesn't solve all security issues, it does rule out one more way in, and for that reason alone it *probably* should be done (if the client actually cares). I do believe it is possible to use flash with security matching those of html based sites, as long as actionscript is treated in much the same way as _javascript_ and html is ie. concerned with the user interface and little else. I recently completed a large project for bbc sport with stupid levels of security, but it was possible by using a single url to handle all data calls, with the actual data itself being written in by the user or the session information pulled back from the server during runtime. A while ago I had a look at the possibilities of a secure highscore table for flash games, but came to the conclusion that it was virtually impossible to guarantee unless you employed some kind of user login. bah. I guess we're a long way off flash banking :) Rob
On 1/8/06, John Grden <[EMAIL PROTECTED]> wrote: Well, that's all true enough, but I would suggest taking these 2 questions seriously if you have a boss/client that'd flip if they knew any Joe off the web could look through they're nice shiney new cutting edge site. YOU know it's harmless, but try explaining that to the guy that just paid out 50g's.
Bob's got great points, and I would suggest people be cautious about leaving the connector in the production version. True, most client's/boss' won't figure it out, but I feel better saying it outloud just incase it *might* be an issue for someone.
On 1/8/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
On Jan 7, 2006, at 8:39 PM, John Grden wrote:
> Yeah, I have to agree. Xray or not, you still have to validate the
> data coming from the client - whether you protect your methods/
> properties correctly or not.
>
> So, in saying that, locking down whether or not Xray exists in a
> site at production seems reduced to this line of questions:
>
> 1. Are you talking to a server and transimitting data? If yes,
> remove xray from the production files.
Why bother? It makes it slightly less convenient to see what's going
on, but it's not impossible. If you're worried about that then you
really need to spend more time with the server to make sure it's
robust against tampering.
> 2. If no, do you care if people look around your flash site with
> Xray (though harmless to the site itself)? if yes, remove xray from
> the production files.
Again.. if the user wants to pick it apart, it's not that big of a
deal. It's absolutely possible to develop a transparent proxy that
injects Xray or anything else into every SWF that goes across the
wire if one were so inclined. The technology to implement this is
readily available -- and the developers on this list are largely to
thank (or blame) ;)
Hell, such a tool would actually be useful for developers. They
wouldn't even need to bother inserting Xray in their projects
anymore, and it would render this discussion completely irrelevant.
My point is -- if you don't want a user to see something, don't ever
send it to them! Otherwise, what's the harm in making it somewhat
accessible? They could see it if they really wanted to anyway.
-bob
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
John Grden - Blitz
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
~~~~~~~~~~~~~~~~~~~~~~~~
Rob Bateman - Flash Product Manager
BBC News Interactive
Tel: 0208 6248692
Mob: 07714 329073
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ osflash mailing list
|
