Forums » Impact Engine » No Global object.

Suppose I have an high score table. I can just go into my browser's inspector and type "ig.game.score = A BAZILLION" and submit my score online, if I want. This is silly.

While window.ig is very convenient when I'm in debug mode, it's incredibly insecure in production.

What I'm suggesting is that we encapsulate the ig variable in a closure instead. So when my entities call "ig.game.<whatever>" they're not referring to "window.ig", but they're referring to some "var ig" that was defined at the beginning of the closure.

Thoughts?

You can accomplish this yourself by changing window.ig to this.ig or var ig (in impact/impact.js), then just compile the files into a single file, wrap everything in a fat self executing function and it should work.

The other workaround you could do is keep important variables inside your defines function and that will protect them as well.

I've discussed this with Dom in the past and he's definitely interesting in making this easier at some point in the future though.

That's fine, except for the fact that it's still going to be possible to modify. Once the code is on the browser side, it's possible to modify it.

All it takes is someone to set up network request tracing in the browser, watch the HTTP request then carry it out themselves, making this little more than security through obscurity...

Arantor: That's different though. What I suggested will prevent any modifications to the app at runtime because the game instance will be completely hidden from any console, etc.

Think you'll find it'll still be accessible in certain browsers' debug panels, even inside that closure, because I've had to pick apart such things in the past.

But for the case presented - hijacking scores, wrapping it up won't make a lot of difference, the path of least resistance will be the way to go ;)

Then please tell me how you can access the computed value of health in the example below?

(function(){

var health = 20 + Math.floor(Math.random() * 10)

})();

There's not a single way you can know that value that I am aware of; unless you hacked your JavaScript engine, or manipulated the JS file before it was even loaded in your browser, both non-trivial tasks.

The fact is, wrapping your application in an anonymous execution context goes MILES to providing a secure runtime space that can't be manipulated by outsiders. And it makes tremendous sense to have it performed automagically on baking, while keeping it referenced in development for debugging.

That's a bad example; once the function executes of course it goes out of scope and becomes fodder for the GC.

Putting aside the issues with modifying it in place - and Google's V8 certainly used to let you do weird things like that (because everything still existed in the depths of 'window', though whether it still does or not, I have no idea, I haven't written anything in Impact in months, moved all my game development to Unity, long story), manipulating the JS file before even loading in the browser... it might be a non trivial task to others, but to anyone who is a web developer, it's really not a difficult task.

Dump it all on localhost in a folder, call it up, you can change it as you like as the files are on your computer.

From practical considerations, you're still going to need to protect things on the back end when scores are submitted, and all the consideration needs to be there, because as I said, people aren't going to mess around with editing the raw code, they'll just scrape the call home (looking up the code directly if necessary) and spoof it, which is really not hard.

Being blunt, hardening the core script against tampering is a lot of security through obscurity, not actual security. I can see why you want to do it, but it's one measure that actually isn't worth the effort.

My example is actually 100% relevant. You can wrap the entire game execution in an anonymous closure and it's virtually impossible to modify at runtime, unless someone goes to an extreme.

Sure you can download the game to your localhost and run it, but browser cross origin protection will stop you from performing any networking requests. Are you going to recompile webkit to allow you to make cross origin requests? This is just a silly argument.

My point 100% stands. A few simple modifications makes the game incredibly more difficult to hack and will solve for 99% of cheating.

At the end of the day, virtually all security is through obscurity when it comes to code downloaded to a local computer. Even byte code can be hacked if the person really wants too, but that's a pointless argument here and ridiculous to assume someone actually wants to do this.

Also this discussion is pointless, the OP was asking about whether the global object of ig.game can be hidden, and yes, it can, and it's very secure. We aren't talking NSA/Government/Black Ops security here. We are talking about solving 99% of the problem. An anonymous closure does just that.

Chrome allows you to modify JS files in place through the Chrome dev tools: http://stackoverflow.com/questions/12593168/editing-javascript-using-chrome-developer-tools You double-click inside the file in the Source tab.

Besides which, I don't need to edit your JS to submit the score. I can watch the network tab and mimic the request if I wanted using jQuery.

While wrapping everything in a self-executing function will prevent super basic "hacking", it in no way provides any kind of security. None. If someone knows enough to type ig.game.score = a bajillion; into the console, they certainly know enough to intercept network communication and spoof it later.

From that perspective, spending nearly any time trying to secure the code that you send to the users' browsers is wasted.

You're still missing the point. You still can't edit the runtime of the app live. Even if you edit the files, you still aren't restarting the runtime, which can only be done by refreshing the page, which will reset all your file changes.

My point still stands, you can make it a real pain in the ass to do anything. Remember, we are solving for the 99%. Hiding the runtime class and associated modules does exactly this.

Maybe we're miscommunicating here, but I'm pretty sure you're missing the point: the original poster wanted to know how to secure an online high score table. He started from the premise that securing the global object will help that.

It won't. I'm watching the network traffic. I can submit a high score of whatever I like. Secure the global object by wrapping everything in a closure; if I want to submit a high score I can because all your validation is right in front of me if you've done it in pure JS.

Hence the client/server maxim don't trust the client.