JSPatch deployment security policy

There are two security issues with using JSPatch:

1. Transmission security: JS scripts can call any OC method and have very wide permissions. If the code is replaced by a man-in-the-middle attack, it will cause great harm.
2. Execution safety: The issued JS script is very flexible and is equivalent to a small update. If it is not fully tested, crashes may occur, affecting the stability of the APP.

Next, let’s talk about the solutions to these two problems.

Transmission security

Solution 1: Symmetric encryption

If you want to prevent the JS code from being easily intercepted and replaced by a middleman during transmission, the easiest way to think of is to encrypt the code. You can use zip encryption compression or encryption algorithms such as AES. The advantage of this solution is that it is very simple, but the disadvantage is that it is not secure and can be easily cracked. Because the key is stored on the client, as long as the client is decompiled and the password field is found, the code is cracked.

There are also some improvements to this, such as:

1. You can save the password to the keychain, but this method is also unreliable. Just find a jailbroken machine and install the APP, add some code to the APP in a hook way, get the key value in the keychain, and then use it for transmission decryption on all other machines.

2. Issue different keys to each user. However, this is very cumbersome and requires protection of the key request. The backend needs to encrypt the script with different keys each time, which is very complicated.

In summary, symmetric encryption has low security. If you want to slightly improve the security, the complexity of the program will increase.

Solution 2: HTTPS

The second solution is to use HTTPS transmission directly. The advantage is high security. As long as it is used correctly and the certificate is not leaked on the server, it will not be cracked. The disadvantage is that it is difficult to deploy and requires the user's server to support HTTPS, which has a 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 significant reduction in security). For specific authentication methods, see some articles on the Internet, such as this one. If the server already supports HTTPS, using this solution is also a good choice.

Solution 3: RSA verification

Is there a solution that is highly secure, easy to deploy, and has a low threshold? RSA verification is one of them.

The principle of this method is actually the same as HTTPS. It also uses asymmetric encryption, but it is simplified. Asymmetric encryption is only used to verify files, and does not solve the problem of data content leakage during transmission. Our goal is only to prevent data from being tampered with during transmission, and we are not too concerned about data content leakage. The entire verification process is as follows:

1. The server calculates the MD5 value of the script file as the digital signature of the file.
2. The server encrypts the MD5 value calculated in step 1 with the private key to obtain an encrypted MD5 value.
3. Send the script file and the encrypted MD5 value to the client.
4. The client obtains the encrypted MD5 value and decrypts it using the public key stored on the client.
5. The client calculates the MD5 value of the script file.
6. Compare the two MD5 values ​​in step 4/5 (the MD5 values ​​calculated by the client and the server respectively). If they are equal, the verification passes.

As long as the verification is passed, it can be ensured that the script has not been tampered with during the transmission process. Because if a third party wants to tamper with the script file, it must calculate the new script file MD5 and encrypt it with a private key. The client public key can decrypt this MD5 value. If the server is not leaked, the third party cannot obtain the private key.

This solution is as secure as HTTPS, but it is not as difficult to deploy as HTTPS, and one set of code can be used universally. As for its disadvantages: data content leakage, in fact, it is not leaked during transmission, but it will also be leaked when stored locally. If you care about this, you can add a simple symmetric encryption to the script file. This solution has more advantages than disadvantages, and it is recommended. Currently, the JSPatch platform uses this solution.

Finally, there is a small problem. The code saved on the client side may also be tampered with. Do we need to take measures? This depends on individual needs. Because this is not a big security issue, if you can tamper with local files, you almost have all the permissions of the mobile phone. At this time, it doesn’t matter whether the script will be tampered with. If necessary, you can add a simple symmetric encryption.

Execution Security

For medium and large APPs, you need to be cautious when issuing JS scripts. It is possible that a large number of APPs may crash or some other abnormal situations due to negligence. Some mechanisms are needed to avoid this situation. If you want to do it completely, you can divide it into: before the incident (grayscale), during the incident (monitoring), and after the incident (rollback).

Grayscale

First of all, the impact of the problem needs to be minimized before it happens. For medium and large apps, the script cannot be distributed to all users at once. A grayscale mechanism is needed, that is, only a part of the users are distributed at the beginning to see if there will be any abnormal situation, and then gradually cover all users. If conditions permit, it is best to randomly assign grayscale users according to attributes such as model/system/region, so that the least number of people can cover most situations.

monitor

Next, when something happens, we need to know that there is a problem with the script, and we need some monitoring mechanism for the APP, such as crash monitoring, which is generally connected to all APPs, and then other monitoring indicators can be added as needed.

Fallback

Finally, there is the fallback code after the incident. In order to avoid unexpected situations, it is generally recommended that the JSPatch script be executed at startup and not removed during the APP operation. Therefore, the implementation method of this fallback suggestion is to send a command in the background to prevent the APP from executing the JSPatch script the next time it is started.

However, the premise of being able to roll back here is that the APP can receive the rollback command sent by the background. If the script sent causes the APP to crash immediately when it is started, the rollback command will not be received. Therefore, it is recommended to add a layer of anti-startup crash mechanism. After the APP crashes after continuous startup, the script file will not be executed next time it is started.

Grayscale and monitoring small and medium-sized apps can be considered not to use it. The fallback mechanism is recommended for everyone who uses JSPatch. Currently, the JSPatch platform implements the above fallback solution.