6
\$\begingroup\$

Followup to securing-http-data-from-a-javascript-game-to-server.

I'm working on something similar, in that I have a PHP backend and a JavaScript frontend, which plays around with the HTML5 canvas element for drawing.

There will be some heavy client-server communication required, as the player will get timely updates from the server with regards to actions that other players are taking. In turn, the client will update the server with his actions that have been taken.

My question is what is the best way to secure such data? Since the client is basically JavaScript, what are some good ways to secure my game data / game states from being tampered with.

I had a thought (spurred by answers to the previous question), about generating a hash based on the currently active session, storing that in a game state database, and validating it server-side. However, I would imagine that any data sent back to the server via AJAX can be scrubbed for any key that I send back.

\$\endgroup\$

3 Answers 3

17
\$\begingroup\$

Don't trust the client.

It's as simple as that. Any safeguard you can put in place can be broken; and truly safe methods are impossible within the scope of JavaScript.

The best approach is to only trust the client with drawing what you send it and retrieving user input. Giving it anything more is just asking for trouble.

Any information you send to your client should be considered compromised, and any information you receive from your client should be considered a potential attack.

\$\endgroup\$
1
  • \$\begingroup\$ all valid and good points \$\endgroup\$
    – erik
    Commented Nov 25, 2010 at 15:48
5
\$\begingroup\$

about knowing other players' data:

The only real way to prevent the client from knowing something, is not telling it to him.

*ANY* other kind of doing it will be breakable with a variable amount of effort, depending on how strong your system is.


about user's own data:

Anything you need to store, you need to store it on the server: anything that comes from the client are lies.

When the client does something, the server should immediately check if he can do it, and allow him to do it if he can. Save the result on the server if you need to later know what happened. The client should never be authoritative about pretty much anything other than what he would like to do.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ so basically step up the period of my ajax requests and make the client a completely dumb client? that's probably good advice \$\endgroup\$
    – erik
    Commented Nov 25, 2010 at 15:46
1
\$\begingroup\$

I would make the server code validate any information sent by the clients.

For example, if a player can only move 5 px per turn, then if the server receives a request to move more than that, it should either reject it or move the player the maximum amount in the intended direction.

Basically, just prevent the client from having full control to do whatever it likes, and limit it to only the actions you want it to perform.

Having said that, you can never make it 100% secure, if someone hacks the webserver and modifies the server code, that's not your fault (unless you're also responsible for security at the data centre!) So make it clear to the client that you can't be held responsible for all eventualities!

\$\endgroup\$
1
  • \$\begingroup\$ true, at this point i'm not in charge of the data center however :) \$\endgroup\$
    – erik
    Commented Nov 26, 2010 at 10:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .