HI,
Yesterday we found someone hacked into our Title and awarded himself 100K virtual currency. I'm sure about this hack as the Playstream events are showing a clear jump in VC balance from one point to other and only one call of Player_Virtual_Currency_Balance_Change with 100K added to the account.
I need some help to dig info on how this has happened. Can someone help us?
First and foremost, no one "hacked" into your title. They might have hacked a client application, but they didn't get access to the backend. Looking at your title, you activated the options that allow the client to update virtual currency (Settings->API Features). The reason those are off by default (and why there's warning help text on those options in the Game Manager pointing out that they allow clients to cheat) is because turning them on makes it trivially easy for any user to add as much VC as they want to. Our recommendation is always to leave that option off, and use server authoritative logic in Cloud Script or a custom game server to increase player VC, so that you can have custom code to check for and prevent cheating.
HI Brendon,
Thanks for the answer. Yes a "hacked client". But the question still remains as to how the client or to be specific PlayFab API was exposed so easily so that a user could make a AddVirtualCurrency call with all required params? Is the SECRET_KEY to make a API call that easy to obtain? Also shouldn't the API be masked and params encrypted as a default so it not easy for anyone to look at the call via sniffer and understand what changes to make to potential award themselves anything?
As a precaution we will remove those calls as we thought exposing them only for a specific reason wont be obvious; most of our ingame dealings are already done via backend and some via Cloudscript.
Thanks,
Kaushik
I don't think you understand. You turned on the ability for any client to add virtual currency via the Client API. That means that any client, with a valid session ticket - which you get on any login - can increase their VC all they want. They don't need the secret key, in your case. Again, that's specifically why we have that option turned off by default, and strongly advise against turning it on.
As to "masked" or "encrypted", no, that would only help briefly. You're talking about a general purpose computing device for which the local user has 100% control, and the encryption would be local. It's really not hard at all to defeat that. The only real security is had by having the logic for evaluating when to add VC or update a statistic be on the server-side, whether through Cloud Script or a custom game server. That way, you can have logic checks to look for cheating, and update those checks to make sure you're catching anything new that people come up with.
There is no easy solution to security. For every wall that is built, someone builds a taller ladder. The key is to make it cost them more to hack than they are willing to invest.
Got it thanks for the detailed answer. I was under the impression that some basic level of encryption/masking of params would have been done its a common approach nowadays.
Since that only adds a superficial (and easily defeated, since all the code and keys for signing the packets would be readily available on the client) level of security to the packets, and runs the risk of falsely giving the impression of real security, it's not something we've invested in. Realistically, the best way to prevent cheating in games is by having the authoritative logic on the server side, where it cannot be compromised, and where you can update it as needed to account for any new behaviors you want to prevent.
Hi, I'm looking to write something similar but I'm little alarmed by this post but perhaps I'm misunderstanding.
My simple understanding is that by doing (2) I'm automatically gaining some additional level of security than just going direct to the API. It seems that this isn't the case? It seems that the 'additional layer' is an opportunity for me to write more of my own code to try and detect foul play? Please can you explain where my misunderstand is? Thanks in advance.
Well first, Client API updates of VC are disallowed by default. You have to actively choose to turn them on, which we advise against for the majority of titles (there are exceptions - single player games that are purely ad-revenue funded, or point-of-purchase, for example - but no title dependent on in-app purchases of VC should turn that API call on).
But no, you have to write cheat checking logic into the script, if you want to have one that adds VC. If you just write a script that directly adds VC with no checks, that's still trivial to cheat. Bear in mind that any API call you allow the client to make can be used by a hacker to send the same call with whatever data they choose. Simply put, you cannot trust the client.
Many titles only let players add VC through either 1) real-money purchases and 2) rewards based on specific actions - completing quests, etc. For the latter, they put in checks to confirm (as much as possible) that the player really completed the action in question.
Thanks @Brendan for the clarification. I was hoping that they'd be a non-repeatable anti forgery key that could be sent via https or something similar. Essentially I don't want to have to write the authorization code myself, I rather use a trusted site. Is there anything on PlayFab that will provide non-forgery comms, perhaps with another authentication mechanism?
The messages coming from the client are formed on the client. So anything you add to the client to encode the message is easily discoverable. That's why real security is server-side for these scenarios. There is literally no way to completely protect against a compromised client, since the client is a general purpose computing device entirely under the user's control. Platforms that do protect against this - as much as possible - are ones with specific, dedicated hardware, like consoles, which have hypervisors as part of their solution.
Anti-forgery keys are meant to protect against things like CSRF attacks - so not to protect against a legitimate client from sending bad data, but to protect against another site that gets a user to input data pretending to be the user.
3 People are following this question.
