Sign In Register

How can we help you today?

Start a new topic
Answered

Security issues

Hello Gamesparks,


I am considering using your Baas for my new game and mainly I am looking into leaderboards and social integration. The first thing that I noticed is lack of documentation on security. Is there any ACL feature available on you backend? Furthermore how would one protect the api keys from getting into wrong hands? My understanding is that a unity3d Webplayer is for example really easy to reassemble, in which case the api key would be found easily and anybody with the api key of the app can make requests to the backend. Are there any measures to secure the app and backend?


cheers,

Armin


Best Answer

Hi Armin,


some comments from my point of view, having had problems with hacked scores etc. in the past.


Using Gamesparks, your client app can not manipulate scores directly, but uses an event system to report scores to the backend.

The events reported from your client are sent in the context of an authorized player. While certain access restrictions for players in cloud code may exist depending on context, there are ways to get to most of the databases, properties, scores etc. that your game uses. Security wise, that shouldn't be important for your app, as the attack vector doesn't present itself to any users of the app - they simply don't deal with backend authorization (your GS login) and have no angle to get to your credentials. You can restrict access to the backend for users in your team depending on role with a nice level of detail as well.


The main attack vector for a supreme haxor is hacking the client (app) binary. And it is indeed quite possible to extract the credentials to communicate with your games backend instance, but all the attacker can do is what the exposed events allow him to do and that only in the context of an authorized player. That is obviously still enough to e.g. post faked scores or currency increments, put the beauty of any backend is, that this comes down to a design question - I would simply not report scores or increment currency directly, but instead, let's say for a shooting game, report the object hits etc., and have the backend calculate the totals that get then inserted into the leaderboard directly.



 




A) On your server? If hackers have access to your server, you have more imminent problems. They can just manipulate your website directly. B) The API uses nonces. Even on the client side there are ways to protect your server secret. For example working with your own hmac algorithm based on encrypted versions of your secret. Or: C) There are key storage services that allow infrastructure secrets to be saved off-site. For a game, that's all overkill, because of A)

Also Since we are talking about a website, there is no way of encrypting the keys (as far as I know), And as a hacker I wouldn't even have to reassemble any binaries. Even If we do the approach that you mentioned, e.g. with the object hits, it would still be a piece of cake, I would just have to write a loop over object hit event and there you go, I can have as much as object hits I want.

Why would they want to have access to my server, they can just write a javascript off-site from anywhere using the sdk and my api key. Or am I mission something

"Am I missing something?" was what I meant

your client app is a website too? or why would a website report score relevant events to GS? In any way there are plenty of very well established approaches - absolute security is obviously not possible, but that is all unrelated to GS.

No the client app is not a website, I am just considering to have a website to show the leaderboards. My knowledge of web programming is pretty basic, so I might be missing something here. If I extrapolate from what you are saying, I can just put the scripts on the server and call the relevant methods with out exposing the contents of the scripts in the browser right?

i suggested the javascript sdk for server side java script. that runs on the server. not in the clients browser. but the callback approach is totally doable as well.

Alright perfect I think I got my answers thank you Thomas

Login to post a comment