| Actually, you can only guarantee security if you don't publish the SWF. It's code that runs on the user's machine, if they want to dissect it and change it they will. It's also not possible for some server or the SWF itself to determine if the SWF has been modified or not.
Taking the LocalConnection out is only more secure because it's less obscure, but there's still no real security anywhere. Period. Why bother? If you don't want someone to have some information, don't put it in a SWF.
-bob On Jan 7, 2006, at 12:13 PM, John Grden wrote: LOL I think I finally see what you're saying Rob!
basically, whatever validation you'd have for the connector is unrealistic in that, if the connector is loaded, they'll be able to view the cached version and possibly make the final "load/unlock" call themselves - is that what you're saying?
So, the only thing we could really do is maybe have an Xray loader component that, via localConnection, makes a call to load the connector swf after recieving the URL from YOU at runtime via the Xray interface. This seems to be the most secure solution.
OR, just simply rename the file so that the site can load it. Of course, the problem there is that everyone at that point in time is able to view it via Xray if they just happen to try at the same time you're debugging.
thoughts?
Thanks for your patience Rob ;)
John
On 1/7/06, Rob Bateman <[EMAIL PROTECTED] > wrote:I see what your saying - i think - , but my (badly made) point was that you can only guarantee security if your online swf doesn't contain the connector code. your method still requires X Ray to talk to the app over a localconnection before verification (the sending of the url), and once the connector is active, the hacking can begin! In theory (i hope im not making this up) you could overwrite the methods of the conector to *enable* it manually the url of a secret swf containing the connector is probably as good as any password system, so i'm modifying my suggestion to: having a getstring value passed into the online app for the connector swf url. You're the only person that knows it, so you're the only person that can enable it. The everything else from the X ray end works as normal. Simple! Rob
On 1/5/06, John Grden <[EMAIL PROTECTED]> wrote: Hey Rob, I see what you're saying but I think you missed what I meant about passing a URL from Xray's interface.
Basically, it's baked in anywhere in the swf's. It's something YOU provide to the Xray INTERFACE at runtime and save it if you wish. That URL is passed to the connector via local connection, the connector makes the call to the server using the specified URL and bam, you get back your secure data.
So, you're the one with the Xray interface and the knowledge of the URL, while the connector is still dumb in fact - make sense?
Xray Interface(url) --> connector.load(URL) --> PHP --> connector.onLoad () --> Xray Interface popup for entering data or verifies a client IP
what do you think?
On 1/5/06, Rob Bateman < [EMAIL PROTECTED] > wrote: I've been pondering this problem for a while now, and here are some ideas... Any security provided on the xray interface side is pointless, becaus the swf could be hacked to remove such settings Passwords or urls accessed from inside the server-side swf can be revealed as well with a simple decompile. As far as i see, the only way to ensure security is to not include the connector code in ther server side swf at all. If debugging is required, you could add a getstring to the url (say, debug=true) that is passed through the embed tag to the applcation and triggers a swf with the connector code to load inside the application swf. The swf you load could be inside a password protected directory of the server, which would trigger a password confirmation box. Once the connector swf was loaded, it could set up the relevant connector objects on the _root of the app. Rob
On 1/5/06, Steve Mathews <[EMAIL PROTECTED] > wrote: Couldn't someone just watch what address' are called then do the same
thing (call the page directly)? Sure, they would need to know to look
for that, but it doesn't seem any more secure to me.
Steve
On 12/26/05, John Grden <[EMAIL PROTECTED] > wrote:
> yeah, that's been a thought and discussion for a while now.
>
> the problem is, how do you lock it down?
>
> You can't put a password on the connector nor can you specifiy the local
> connection names - hacking an SWF is yesterday's news, so your proprietary
> information is not secure by any means. All a person does is hack your SWF,
> then they've got all the information they need.
>
> So, it comes down to: How does Xray load external data? Do we put the
> ability to type in a server side script URL, that the connector loads?
> Then, how do you keep someone from cracking your SWF, and calling the PHP
> page directly?
>
> The only thing that comes to mind is using the Xray interface to pass along
> the Server Side Script URL THROUGH the connector - Xray tells the connector
> what URL to call, it calls the page, and now, has the necessary data to do
> validation with the interface (Username/Password). Does that make sense?
>
> XrayInterface(url) -> connector -> url -> connector ->
> XrayInterface.validation
>
> Thoughts?
>
>
> On 12/26/05, Benjamin Jackson < [EMAIL PROTECTED]> wrote:
> > I was wondering about the potential for security breaches is with
> > leaving the Xray debugger active on live sites. On the one hand, it's
> > important to be able to debug the live site if something goes wrong
> > after deployment. On the other hand, it doesn't seem too smart to allow
> > anyone with the debugger execute arbitrary Actionscript on my swf.
> >
> > Any opinions?
> > ___________________
> > Ben Jackson
> > Diretor de Desenvolvimento
> >
> > [EMAIL PROTECTED]
> > http://www.incomumdesign.com
> >
> >
> > _______________________________________________
> > 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
>
>
>
_______________________________________________
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
[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
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
John Grden - Blitz_______________________________________________ osflash mailing list |
