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.
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.
Whether you employ bob's rule or not is up to you. Seems like it's a nice way to make Xray available when you need it.
would everyone agree with this latest thought process?
On 1/7/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
On Jan 7, 2006, at 7:38 PM, John Grden wrote:well, let's say you have a game that requires highscores to be passed. The obvious problem is that with Xray, you can actually change any property you want and execute any code you want.
So, let's say they find you highscore property and they just happen to also find the method that sends the data to the server. With Xray, they could update the highscore, then submit it by calling the method through Xray. So, data integrity to the server becomes the issue.
The concern, i had thought, was over someone snooping around methods/properties/proprietar implementations at runtime with Xray. Other than submitting bogus data, there's not really an issue that I can think of that would do any harm. Like Bob said: Server should never trust the client. I would think that people would still use something like ASV to decompile an SWF if they wanted to see how the app works. They'd use Xray to affect something server side at runtime. So, yeah, I haven't felt a need to pull the Xray connector from any of the sites I've done, but then again, none of them talk to any data source. I could care less if someone wants to know how I did something and if they do it at runtime with Xray, have at it. In fact, if they come away from the experience still able to say their own name and eat normally, hehe, they've earned it ;)It's still not secure. You can't trust the client. It doesn't matter whether it has Xray or not, or if you're sending URLs over the wire at runtime, etc.You really can't have "good" security for this kind of use case unless the server controls the game too. The best you can really do is to have a way to detect abuse. For example, you could -- at the server -- log the time they started playing and estimate the probability a high score was attained in the amount of time it took for the score to be reported. Anything out of the ordinary could be flagged (maybe not shown) and then you could take whatever measures are necessary to deal with the abuse.One other thought: What about adding the ability to specify the domain that Xray should not work on? or a list of domains it should/should not work on? I mean, here's a scenario:
You have 3 locals for your site: local (localhost), staging server (clientName.mydomain.com), production server ( www.clientDomain.com )
You put Xray on stage, and you define an array of domains it SHOULD work on: localhost, clientName.mydomain.com
When you finaly push it to production, Xray doesn't work, but in staging and local, it does.It's easy to fake all of that...-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
