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.



 




I have been testing everything today, and I have to say I am loving this platform. Especially the feature to be able to build custom code as events and then downloading them directly to the SDK, this is brilliant.


I am still unsure about the security issues though, as I have mentioned in the last question. So any input from developers would be much appreciated. I would also love to know how the sdk handles the autologin, from the tests that I have done, it seems like the session persists even after application quit( at least editor stop in Unity3d). Is this reliable or should I store the session and username in PlayerPrefs and load them after application start?


cheers,

Armin

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).

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

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 Thomas,


thanks for the insight, But I could not quiet understand the difference here. If someone can upload scores then they definitely can upload object hits there are just numbers as far as I can see, or am I missing something?

Object hits, in my example, are just triggered events, which is just an api call without attributes. The actual score values are held server side. Let's say shooting an Alien gets you 10 points. Instead of doing score+=10, you trigger "Player hit alien". Sure, if someone wants to extract the api key and secret, and build their own client or manipulate your client heavily, they can create a client that calls the the "player hit the alien" event a million times. While you would always have that problem, with any service, the actual attack gets quite complex very quickly depending on the object structure of the game and how much of the game state is held server side - out of reach for cheaters. In other words, the more of the processing of rewards, score etc. you do server side, the less manipulation is possible on the client side. You have additional measures at your disposal, like checking the user behavior against certain standards to verify "real" players etc. If it's worth going that far depends on the value of your data. The classic cheater just looks for a number he can patch in order to have the best rank on the leaderboards.

Ah alright, gotcha! And while I have you here, maybe I can also ask you about user registration. I am thinking to totally abandon the idea of Email/Username/Password paradigm altogether, since I would need to send a verification link to the user, which then would require exposing the api key in javascript, which every kid can view in their browser and manipulate. What are your thoughts on this? 


PS: I have not seen any Game Baas that would offer such service with enough security 

If you can live with device dependent registration, meaning that the same user would not be able to play the same account on his e.g. iPad than he is playing on his phone, you can do that. But Gamesparks makes it super easy to use another, already existing Identity, such as Facebook, Google Account, even Game Center and more. You don't have to expose anything if you chose that option. Regarding email verification you have several options: If you don't want to use your own server as a proxy (registration load should be easy to deal with), you still have several options:


* You can just use the callback feature in the game. While this reveals your api key, it does not reveal your api secret, as there is an extra server secret for outside server access.

* If you don't want to reveal anything, you just start an additional Gamespark project and use it's callback url for verification links - you then ping back to the actual game via it's own callback url or via rest api using SparkHttp.

Hello Thomas,


I am still researching on the subject, So I decided to go with device authentication and social login, I think that should be enough for my purposes. However just out of curiosity I would love to know more about the solution you mentioned namely :

"You can just use the callback feature in the game". Because I think I can use this technique else where. So I started reading this link:

https://docs.gamesparks.net/howtos/cloud-code-scripting/how-to-implement-external-http-callbacks


There are some points I don't understand though, lets say I want to setup a web page to show the leaderboard of my game (completely decoupled from the actual game) on a website, as far as I can understand, I hit the callback with api and server secret from my html page. Then a cloud code gets executed. How can I get the data back though ? Am I understanding this correctly? Or this is a wrong use case for cloud code ? Should I just make api calls directly the same way I do it on the client app and secure everything with roles?


PS: My head is spinning from all this security talk


That would be an unusual use for the callback. I use callbacks for cases like: Someone signs up to one of my games on my (regular) website, for example because I promise him a reward if he/her signs up from there. I notify the GS backend about his credentials via Callback, to be able to verify his identity in the actual client app and then give him/her the reward.

Or simply to check if an out-of-app ad click results in an install. Stuff like that. 

But nothing is impossible, if you were to hit the callback URL to request data, the cloud code you attach to it would need to fetch the data you want and then send it to your website using Sparkhttp, e.g. via http POST and there you would use whatever scripting language (php etc.) to process the data and display. But that's most likely a few steps to complicated.


For getting leaderboard data onto my website, personally, I would most likely just use Server Side Javascript with the GS Javascript SDK. Using a "Management" User to get to the leaderboard data - simply because the documentation is practically non  existing for using the websocket services directly and I probably wouldn't want to waste the time to figure out how it works.



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

Login to post a comment