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.



 




Hi Armin,


Could you elaborate on your requirements in relation to ACL ? Our service is fully secure, it's a Unity (or any other front end you end up using) issue that would allow them to be accessed from the front end, some custom security measures would need to be implemented by developers to combat this.


Once a user is logged into the the game, the auth token is cached locally in the GS library and auto renewed when the player reconnects, the user will only have to re enter their details once until they fully logout. If you look at the player system collection in NoSqL you can see a list of auth tokens that are stored against the player.


Thanks,

Liam 

Hi Liam, 


thanks for the answer. As far as I know there are two levels of security ( at least the way your competitors like Parse and App42 use them) Lets take Leaderboards for example, First there is ACL, where one sets permissions on the score class itself so that every user has write permissions on his own score and only read permission on the scores of other users. Secondly there ist custom API keys where one could grant access only to a subset of APIs, so that even if the someone gets the hold of the api key, they would only be able to call those particular apis. 


Does that make sense ?


cheers,

Armin

Hi Armin,


You’re correct in terms of ACL, it’s fundamentally built into the platform that an Authenticated user can only read/write their own data and read the data of other users. For the secret you could implement an override for it in GameSparks.Platforms.WebGL.WebGLPlatform that will allow you to secure this however you like.


Whilst you wouldn't be able to grant access with a subset of APIs in your game you could configure something similar in the portal where you could essentially lock users so they would only be able to trigger certain events depending on their role. We have an example game setup for this in place if you’d like we can add you to it so you can become familiar with how this could work for you.


Thanks,

Liam

I wouldn't rely on the session (authentication token) persisting for keeping the user always logged in. It normally works, but I don't think it's something to rely on 100% (e.g. in scenarios like having a backup of the app and installing on another device).

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.



 



Hello Liam,


thanks for the clarification, I didn't quiet understand the matter with "secret" and overriding it in GameSparks.Platforms.WebGL.WebGLPlatform, could you elaborate on that or point me to the right direction?


I would also like to be added to this example if this is possible.


cheers,

Armin G Jazi

Hello Thomas,


forgive me for sounding like a broken record, but lets say I use the Javascript SDK and try to show the leaderboards on my website, With this I compromise my api key and everything is accessible from the outside world. E.g. as a hacker I could write a javascript with the same sdk and would first call gamesparks.registerationRequest, then gamesparks.authenticationRequest and voila i can call the logevents and I can post a fake highscore. And keep in my mind im not even a seasoned hacker. Am I missing something or there is something wrong with the way security is being handled by Gamesparks?


cheers,

Armin

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