Can variables in JS function closures be accessed in any way (including devtools)? How?

Question

In my previous question: Securing javascript game timing

... it became clear that client-side timing in a Javascript/Canvas game simply won't be secure. I know the mantra about not trusting the client - that is what is causing my struggle in the first place.

So, if I do move all timing to the server and just deal with it, here is a follow-up question. The game obviously needs to be completed before submitting it. As the game puzzle is all Javascript, this introduces the problem of manipulating the client-side code to fake the completion of the game.

I've created the game JS code in a separate class file. If I instantiate the game as such:

var game;
$document.ready(function(){
  game = new Game();
});

... then, I can access the 'game' object and all of its methods and variables via the console.

However, if I do:

$document.ready(function(){
  var game = new Game();
});

... then I cannot access the 'game' object through the console. This seems to help, but is there something I don't know - can this object still be accessed in some way I don't know about or is making it a private var in that function a little more secure?

Answer 1

Note: there are many other security considerations and attack vectors in such a system. This answer just seeks to answer the specific question that was asked here.

It depends on the browser and what its devtools provide. Most browsers' devtools provide functionality to:

• pause execution of JavaScript at any point in time and use a debugger interface.

  • Variables that are in-scope at the current point of execution where the debugger is paused can usually be accessed via devtools in various ways. Inparticular, via console, where anything one can do with that variable in the console is fair game: query its fields, call its methods, etc. If the variable binding isn't const, one can even reassign the variable to a new user-created instance of the object.

• navigate JS files and set breakpoints in them.

  • This is a vector to the above bullet point.
  • You can make this less attractive by using JS minification (ie. obfuscation), but that's not going to stop someone who's determined.
    • String literals don't get minified and can usually help a lot in navigating and understanding minified code.

• inspect event listeners on HTML elements and set breakpoints on them.

  • If a variable has a reference bound to it in a function closure that is known to be an event listener of a certain HTML element, or reachable (execution-wise) by such an event listener, this can be another vector to the first bullet point. This can be very common in web games. Just a keyboard event listener usually is an entry-point to reach functions that reference important game objects.

• There are even tools to record the JS heap memory. It's a lot of data to sift through, but it's basically everything on the JS heap (readonly).

Given those browser features (and the fact that a user can use any browser they wish), it's impossible to "safeguard" anything 100% on the client-side. It's a losing battle. If you want to play it like a game, you can do your best.

• Look into Object.freeze and friends.
  • Freeze or seal anything that can be frozen or sealed, including class prototypes
• Make variables which can be const const
• Use assertions to assert in critical parts of the logic that the program state is consistent and try to detect tampering.
• Make the production version of your site annoying to use the devtools with, such as putting something like setInterval(() => { eval("debugger;"); }, 100) to spam breakpoints. See also my answer to "Find out whether Chrome console is open" for techniques to detect whether devtools are open, which you can then use to trigger things like closing the page (a bit overkill, but you can think of other ideas).

Answer 2

Don't care too much about the console. Yes, if there are global objects whose method can easily be fired to "win" the game, it's a nice possibility to cheat, but it can easily prevented as you demonstrated.

So, the hacker would just listen (look at the network pane) which requests are made to your server and fire them manually. If they were just some simple urls like /action=start and /action=end, he could very easily fire them manually without any timing. So you will need to prevent that (although you never can really make it safe), e.g. by adding additional credential tokens. Or you could embed some "secret"(s) into the game code, which are revealed during the gameplay, and need to be sent to the server to prove the rightfulness. Of course they could be read out of your code, but you have to make it too complicated for the hacker. It's a bit like security by obscurity…