CODEWITHSUNDEEP
javascriptajaxhtmlsecurity
yasa
yasa

Reputation: 41

Webapp security for client-side game logic operations

I am working on an in-browser game, taking advantage of the Canvas available in HTML5. However, I realized that I have a big vulnerability in the system. The game score and other statistics about game play are calculated on the client-side in Javascript, then submitted to the server for storage and comparison to other players through XMLHTTPRequest. This obviously exposes the statistics to manipulation and potential cheating.

I am worried about moving these to the server-side due to latency issues. I expect the timing to be close.

Are there other smart ways to deal with this problem? I imagine more and more games will deal with this as HTML5 grows.

Upvotes: 4

Views: 747

Answers (4)

JoshuaBoshi
JoshuaBoshi

Reputation: 1286

The 100% security is not achievable when you have to trust to data from client. However, you can make it hard to cheat by obfuscating the js code and also the data that you send from client.

I have got an idea that is similar to gviews comment.

On the server, you should keep track of the players process of the game by batch updates, that you will send from client regularly in some interval... Player will not recognize it in the latency, and you will have the tool to detect obvious cheaters. You know the starting point of the players game, so you can easily detect the cheating right from the beginning.

Also, i would suggest to use some checkpoints where you would check the real state of the game on client and the state on the server. (the state of the client would not change if the cheater changes only the server updates by xhr).

There is lot of ways to make it harder to cheat, and it is quite individual for each game... there is no standard that solves it all.

Upvotes: 0

Will
Will

Reputation: 20225

Unfortunately there is not much you can do about this. Minifying/obfuscating your code is always a good option. I'm not entirely sure, but I think putting your code inside

(function() { /* code */ })();

should protect any variables from users editing (unless you have them attached to an object like window). But users can still exploit your ajax call and send whatever score they want to the server. Just, never trust anything that is done client side. Validate everything server-side.

EDIT: Another thing I thought of: maybe generate a code server-side, and send that to the browser. Then with every ajax-call send that code to verify that it is you and not some malicious user.

Upvotes: 0

liamzebedee
liamzebedee

Reputation: 14490

Why don't you just send data to the server every time the client scores a point and then keep a local score of points.

Upvotes: 0

gview
gview

Reputation: 15361

Not really. Your server in this scenario is nothing more than a database that trusts the client. You can obfuscate but people will be easily able to figure out what your api is doing. This is an intractable problem with all standalone games, and is why for example, you see Blizzard making Diablo3 a client-server game. The fact that it's a javascript game just makes it even more transparent and easy for people to debug and exploit.

Upvotes: 1

Related Questions