JSPatch 部署安全策略

使用 JSPatch 有两个安全问题：

1. 传输安全：JS 脚本能够调用任意 OC 方法，权限很是大，若被中间人攻击替换代码，会形成较大的危害。

2. 执行安全：下发的 JS 脚本灵活度大，至关于一次小型更新，若未进行充分测试，可能会出现 crash 等状况对 APP 稳定性形成影响。

接下来讲下这两个问题的解决方案。

传输安全

方案一：对称加密

若要让 JS 代码传输过程当中不轻易被中间人截获替换，很容易想到的方式就是对代码进行加密，能够用 zip 的加密压缩，也能够用 AES 等加密算法。这个方案的优势是很是简单，缺点是安全性低，容易被破解。由于密钥是要保存在客户端的，只要客户端被人拿去反编译，把密码字段找出来，就完成破解了。

对此也有一些改进方案，例如：

1.能够把密码保存到 keychain 上，但这种方式也是不可靠的，只要随便找一台机器越狱装了这个 APP，用 hook 的方式在 APP 上添加一些代码，得到 keychain 里的密钥值，就能够用于其余全部机器的传输解密了。

2.给每一个用户下发不一样的密钥。但这样就很是繁琐，须要对下发密钥的请求作好保护，后台须要每次都对脚本进行不一样密钥的加密操做，复杂性高了。

综上，对称加密安全性低，若要稍微提升点安全性，就会提高程序复杂度。

方案二：HTTPS

第二个方案是直接使用 HTTPS 传输，优势是安全性高，只要使用正确，证书在服务端未泄露，就不会被破解。缺点是部署麻烦，须要使用者服务器支持 HTTPS，门槛较高。另外客户端须要作好 HTTPS 的证书验证（有些使用者可能会漏掉这个验证，致使安全性大降），具体的认证方式可见网上一些文章，例如这篇。若是服务器原本就支持 HTTPS，使用这种方案也是一种不错的选择。

方案三：RSA 校验

有没有安全性高，部署简单，门槛低的方案？RSA 校验就是。

这种方式其实原理跟 HTTPS 是同样的，一样使用非对称加密，只是简化了，把非对称加密只用于校验文件，而不解决传输过程当中数据内容泄露的问题，而咱们的目的只是防止传输过程当中数据被篡改，对于数据内容泄露并非太在乎。整个校验过程以下：

1. 服务端计算出脚本文件的 MD5 值，做为这个文件的数字签名。

2. 服务端经过私钥加密第 1 步算出的 MD5 值，获得一个加密后的 MD5 值。

3. 把脚本文件和加密后的 MD5 值一块儿下发给客户端。

4. 客户端拿到加密后的 MD5 值，经过保存在客户端的公钥解密。

5. 客户端计算脚本文件的 MD5 值。

6. 对比第 4/5 步的两个 MD5 值（分别是客户端和服务端计算出来的 MD5 值），若相等则经过校验。

只要经过校验，就能确保脚本在传输的过程当中没有被篡改，由于第三方若要篡改脚本文件，必须计算出新的脚本文件 MD5 并用私钥加密，客户端公钥才能解密出这个 MD5 值，而在服务端未泄露的状况下第三方是拿不到私钥的。

这种方案安全性跟 HTTPS 一致，但不像 HTTPS 同样部署麻烦，一套代码便可通用。对于它的缺点：数据内容泄露，其实在传输过程当中不泄露，保存在本地一样会泄露，若对此在乎，能够对脚本文件再加一层简单的对称加密。这个方案优势多缺点少，推荐使用，目前 JSPatch平台 就是使用这个方案。

最后有个小问题，保存在客户端的代码也可能被人篡改，需不须要采起措施？这个要看各人需求了，由于这个安全问题不大，能篡改本地文件，差很少已经有手机全部权限了，这时也无所谓脚本会不会被篡改了。如有须要，能够加个简单的对称加密。

执行安全

对于中大型 APP，下发 JS 脚本须要谨慎，有可能由于疏忽下发了有问题的代码，致使大量 APP crash，或一些其余异常状况，须要有一些机制避免这种状况。若要作得完整，能够分为：事发前(灰度)，事发中(监控)，事发后(回退)。

灰度

首先须要在事发前把出现问题的影响面降到最低，对于中大型 APP，不能一次把脚本下发给全部用户，须要有灰度机制，也就是一开始只下发给其中一部分用户，看看会不会出现异常状况，再逐步覆盖到全部用户。有条件的话灰度的用户最好按机型/系统/地域等属性随机分配，尽可能让最少的人覆盖到大部分状况。

监控

接着是事发了咱们须要知道脚本有问题，须要对 APP 有一些监控机制，像 crash 监控，这个通常全部 APP 都有接入，再按需求自行加入其余监控指标。

回退

最后是事发后回退代码。通常为了不不可预料的状况出现，JSPatch 脚本建议在启动时执行，APP 运行过程当中不去除，因此这个回退建议的实现方式是后台下发命令，让 APP 在下次启动时不执行 JSPatch 脚本便可。

但这里能回退的前提是 APP 能够接收到后台下发的回退命令，若由于下发的脚本致使 APP 启动即时 crash，这个回退命令也会接收不到。因此建议再加一层防启动 crash 的机制，APP 在连续启动即 crash 后，下次启动再也不执行脚本文件。

灰度和监控中小型 APP 能够考虑不用，回退机制是每一个使用 JSPatch 都建议加上的。目前 JSPatch平台 实现了上述回退方案。