Security
Securing your application is the most important things when developing an application.
Since the specification of the Kii Cloud is open, any attackers who know your application's access key (AppID) can imitate your application and access the Kii Cloud. This, however, does not mean they can exploit your users' data. As long as the user data are protected with the proper access control, they are safe even if the access keys are leaked.
On the other hand, the application admin credentials (i.e. ClientID and ClientSecret) must not be leaked at any cost. Any attackers who get these credentials will gain full access to all user data.
This section covers some tips on the application security. When developing your mobile application, you need to be aware of the possible risks and design your application so as to protect your application data with the security features provided by Kii Cloud.
Risk of Leaking Access Keys
As introduced, any attackers having your application's access key (AppID issued by Kii Cloud) will be able to access Kii Cloud as if they are your application.
Obtaining your application AppID is not that hard; a skilled attacker, for example, may get them by reverse compiling your application or by referring to your JavaScript file. Once they got the keys, they can execute some REST APIs to mimic the access from your application.
Please note that an attacker cannot get your users' passwords by executing REST APIs. This means that they cannot compromise the user data if the data are protected with the appropriate access control:
All user-scope data, by default, can be only accessed by the user. An attacker without the user's password, therefore, cannot access the data.
All group-scope data, by default, can be only accessed by the users who belong to the group. An attacker without the member's password, therefore, cannot access the data.
In short, user-scope and group-scope data are free from the exploitation as long as the target user's password is secured.
Application-scope data
Application-scope data, by default, are accessible by any authenticated users. This means that they are also open to any attackers who get your application's access keys. Once they get the access keys, they can easily create a new application user and access the data as this user.
In the following example, we are storing a high score of a game as an application scope data. The high score data is vulnerable to attackers because they can easily access and modify it.
Completely preventing the exploitation is hard, but you can alleviate the issue by leveraging the server extension feature as follows:
Remove the write permission of any authenticated users from the application scope (you can do this as an application admin). Then, grant the write permission to the scope by a specific user.
Deploy server code for updating the high score data as the specific user configured in the previous step.
Implement your application in a way that it requests the server code for updating the high score. Upon the request, you can add some tweaks to obfuscate the update request (e.g. sending an evidence of the high score, like some internal states of the game, as a parameter). By introducing the server code in the sequence, you will be able to conceal some of the logics used for the obfuscation (e.g. which internal states are used).
Risk of Leaking Admin Credentials
Anyone with the application admin credentials (i.e. ClientID and ClientSecret) will gain the application administrator privileges and will be able to update any users' data. Leaking your admin credentials, therefore, will spoil your service since an attacker will have full control over all your application data.
It is important to not to embed your admin credentials in your application. Embedding the encrypted credentials in the application is not safe because attackers can reverse compile your application and decrypt the credentials.
If you need to use the admin features from your application, you should use the server extension feature. The server code is maintained in Kii Cloud and is only accessible to the app administrator. Since attackers cannot get your server code, you can put your ClientID and ClientSecret in the code with little risk. Still better, you do not need to put your ClientID and ClientSecret at all since the server extension allows you to use the app administrator token (See this sample code to learn more).
If Admin Credentials are Leaked...
If there is a possibility that the ClientID and ClientSecret leaked to the outside, reset the ClientSecret on the developer portal immediately.
After resetting, the current ClientSecret will be invalidated and a new ClientSecret will be assigned. For the security reason, all access tokens that have been issued before the reset will be invalidated as well.
Obfuscating the Implementation
In general, just obfuscating your application logic only provides you a weak application security. Skilled attackers will reverse-compile your application and will figure out how your obfuscation works. This is especially true for the mobile application for which attackers can easily obtain the executable code for the analysis.
Here is an example. Suppose that you want to create an application with Kii Cloud on which you do not want your user to enter a username and password. You could do this by randomly creating a username and cipher it to create the corresponding password.
This implementation ensures the security by hiding the password generation logic. If an attacker analyzes the application and finds how the password is generated, he can easily generate the valid password by only knowing the username and thus be able to access user-scope and group-scope bucket and data.
You should be prepared for this kind of reverse compiling attack. How complicated your cipher logic is, an attacker will eventually "hack" the application.
In this case, randomly generating a password is better. Your application can store the randomly generated username and password inside the device storage. In this way, an attacker cannot determine the valid password from the username. Even if the attacker reverse-compiles the application and figure out how the password is generated, he will need to access the user's device directly to get the valid pair of the username and password.