this article reprinted to http://blog.cnbang.net/tech/2879/UseJspatchThere are two security issues:
- Transport Security: JS script can call any OC method, the permissions are very large, if the man-in-the-middle attack to replace the code, it will cause great harm.
- Implementation of security: The JS script issued a large flexibility, equivalent to a small update, if not fully tested, there may be crash and other conditions on the stability of the APP impact.
Next, the solution to these two problems.
Transport security Scheme one: symmetric encryption
To make the JS code transfer process is not easily intercepted by the middleman to replace, it is easy to think of the way is to encrypt the code, can be compressed with zip encryption, you can also use AES and other encryption algorithms. The advantages of this scheme are very simple, the disadvantage is that the security is low, easy to be cracked. Because the key is to be saved in the client, as long as the client is taken to decompile, the password field to find out, the completion of the hack.
There are also some improvements to this, such as:
1. The password can be saved to keychain, but this way is also unreliable, as long as a random machine jailbreak installed this app, Hook way to add some code in the app, get the key value in keychain, you can use for all other machine transmission decryption.
2. Give each user a different key. But this is very cumbersome, need to be issued a key to protect the request, the background needs to be each time the script for different cryptographic operation of the key, the complexity is high.
In summary, symmetric encryption security is low, to slightly improve the point of security, it will increase the complexity of the program.
Scenario Two: HTTPS
The second scenario is the direct use of HTTPS transmission, the advantage is high security, as long as the use of the correct, the certificate is not compromised on the server, it will not be cracked. Disadvantage is the deployment of trouble, requires the user server to support HTTPS, high threshold. In addition, the client needs to do a good job of HTTPS certificate verification (some users may miss this verification, resulting in a large security drop), the specific authentication method can be seen online some articles, such as this article. This is a good choice if the server is inherently HTTPS-enabled.
Scenario Three: RSA checksum
Is there a solution for high security, simple deployment and low threshold? RSA checksum is.
This method belongs to the digital signature, with the same asymmetric encryption as HTTPS, only simplifies, the asymmetric encryption is only used to verify the file, not to solve the problem of data leakage in the transmission process, and our purpose is to prevent the transmission process of data tampering, the data content leakage is not too concerned about. The entire verification process is as follows:
- The server calculates the MD5 value of the script file as a digital signature for this file.
- The service side encrypts the MD5 value by the 1th step of the private key, and obtains an encrypted MD5 value.
- The script file is sent to the client together with the encrypted MD5 value.
- The client gets the encrypted MD5 value, which is decrypted by saving the public key on the client.
- The client calculates the MD5 value of the script file.
- Compare the two MD5 values in the 4th/5 step (the MD5 values computed by the client and the server), and pass the checksum if they are equal.
As long as the verification, can ensure that the script is not tampered with in the process of transmission, because the third party to tamper with the script file, must calculate a new script file MD5 and private key encryption, the client public key to decrypt the MD5 value, and in the case of the server is not compromised, the third party cannot get the private key.
The security of this scheme is consistent with HTTPS, but unlike HTTPS, a set of code can be common. For its shortcomings: the data content leakage, in fact, in the transmission process does not leak, save in the local will also be leaked, if you care about this, you can add a layer of simple symmetric encryption of the script file. The advantages of this scheme are many shortcomings, recommended use, the current Jspatch platform is the use of this program.
Finally, there is a small problem, the code stored on the client can also be tampered with, need not take action? This depends on the needs of each person, because this security problem is not big, can tamper with local files, almost already have the phone all permissions, then it doesn't matter whether the script will be tampered with. If necessary, you can add a simple symmetric encryption, or verify the MD5 value once each time as described in the above process.
Perform security
For medium-sized apps, a JS script needs to be cautious, possibly due to inadvertently issued the problematic code, resulting in a large number of app crash, or some other abnormal situation, need some mechanism to avoid this situation. To do complete, can be divided into: Before the incident (grayscale), the incident (monitoring), after the incident (back).
Gray
First need in the incident before the impact of the problem to the minimum, for medium-sized apps, can not be issued to all users of the script at a time, need to have a grayscale mechanism, that is, a start only to a subset of users, to see if there will be abnormal situation, and then gradually cover to all users. If you have the condition, gray-scale users should be assigned randomly according to the model/system/region properties, so as to minimize the number of people to cover most cases.
Monitoring
And then it happened. We need to know that there is a problem with the script, need to have some monitoring mechanism for the app, like crash monitoring, this general all apps have access, and then add other monitoring indicators on demand.
Fallback
Finally, the post-incident fallback code. Generally in order to avoid unforeseen circumstances, the Jspatch script is recommended to execute at startup, the app does not remove the process, so this fallback proposal is implemented in the background command, so that the APP will not execute the Jspatch script on the next launch.
But the premise is that the app can receive back orders issued in the background, if the script caused by the app to launch the instant crash, this fallback command will not be received. Therefore, it is recommended to add a layer of anti-boot crash mechanism, the APP after a continuous boot is crash, the next boot no longer executes the script file.
Grayscale and monitoring small-to-medium apps can be considered without a fallback mechanism that is recommended for each use of jspatch. At present, the Jspatch platform realizes the above-mentioned fallback scheme.
Jspatch Deploying security Policies