It's not my rule, it's just basic security.
If your SWF is able to do bad things to your server, then you have a problem and there isn't a damn thing you can do in the SWF that's going to make that problem go away. The server shouldn't ever trust the client.
It's actually easier to find those sorts of flaws with a traffic analyzer than an ActionScript disassembler or debugger anyway. Even if it's over HTTPS, the Flash plugin is trusting the ActiveX or netscape plugin host to perform the HTTPS anyway so it's easy to man-in-the-middle that by replacing or modifying. Maybe the tools for that aren't quite so widely available, it's still easy to code (trivial even, on a Mac anyway given WebKit).
-bob
On Jan 7, 2006, at 1:54 PM, Rob Bateman wrote: Is this a concern over protecting actionscript code or a concern over protecting sensitive information (like passwords) If it's the former then I agree with Bob, you are powerless to stop people getting their hands on your code *eventually*, and the whole excercise is meaningless. If it's the latter, then this is just sticking to the principle of 'no sensitive information in the swf' allowing access to an X ray debugger could be considered a security risk, so the whole thing makes sense. John, is there any example you can think of of someone could use X ray for 'evil' ends? By which i mean ends that affect the website database or whatever else a swf could access? If we're following bob's rule (which i think this should be christened as, btw) then in theory there shouldn't be any risk at all... what your then left with is a security risk that involves hacks snooping round your classes going 'ooo, he's used a multidimensional array to iterate the properties etc...' which i think i for one could live with. Maybe i'm missing something. Rob
On 1/7/06, John Grden <[EMAIL PROTECTED]> wrote: "Actually, you can only guarantee security if you don't publish the SWF"
I think some are missing what I've been saying becuase, this is EXACTLY what I've been saying: no URL / Password/ Username /IP would be published with any SWF at all.
You have a dumb connector and you have an interface. They talk via localConnection.
If you tell your application to load the connector SWF, and the file DOES exist, it loads. Otherwise, if fails silently.
How does the app know where to get the connector SWF? YOU tell it through the interface (Xray interface where you take snapshots - physically type it in), which tells your application the URL for the connector.
So, there's no information that's published in any swf at all. If someone caches your SWF's and views them with ASV, they get nada/nothing. The developer has to know the URL of the connector or it's all over.
So, no proprietary information is ever in any of the SWF's.
Have I missed something in this scenario? thoughts?
_______________________________________________
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
|
