摘要：綜上，對稱加密安全性低，若要稍微提高點安全性，就會提升程序復雜度。對于它的缺點數據內容泄露，其實在傳輸過程中不泄露，保存在本地同樣會泄露，若對此在意，可以對腳本文件再加一層簡單的對稱加密。

使用 JSPatch 有兩個安全問題：

傳輸安全：JS 腳本可以調用任意 OC 方法，權限非常大，若被中間人攻擊替換代碼，會造成較大的危害。

執行安全：下發的 JS 腳本靈活度大，相當于一次小型更新，若未進行充分測試，可能會出現 crash 等情況對 APP 穩定性造成影響。

接下來說下這兩個問題的解決方案。

若要讓 JS 代碼傳輸過程中不輕易被中間人截獲替換，很容易想到的方式就是對代碼進行加密，可以用 zip 的加密壓縮，也可以用 AES 等加密算法。這個方案的優點是非常簡單，缺點是安全性低，容易被破解。因為密鑰是要保存在客戶端的，只要客戶端被人拿去反編譯，把密碼字段找出來，就完成破解了。

對此也有一些改進方案，例如：

1.可以把密碼保存到 keychain 上，但這種方式也是不可靠的，只要隨便找一臺機器越獄裝了這個 APP，用 hook 的方式在 APP 上添加一些代碼，獲得 keychain 里的密鑰值，就可以用于其他所有機器的傳輸解密了。

2.給每個用戶下發不同的密鑰。但這樣就非常繁瑣，需要對下發密鑰的請求做好保護，后臺需要每次都對腳本進行不同密鑰的加密操作，復雜性高了。

綜上，對稱加密安全性低，若要稍微提高點安全性，就會提升程序復雜度。

第二個方案是直接使用 HTTPS 傳輸，優點是安全性高，只要使用正確，證書在服務端未泄露，就不會被破解。缺點是部署麻煩，需要使用者服務器支持 HTTPS，門檻較高。另外客戶端需要做好 HTTPS 的證書驗證（有些使用者可能會漏掉這個驗證，導致安全性大降），具體的認證方式可見網上一些文章，例如這篇。如果服務器本來就支持 HTTPS，使用這種方案也是一種不錯的選擇。

有沒有安全性高，部署簡單，門檻低的方案？RSA 校驗就是。

這種方式其實原理跟 HTTPS 是一樣的，同樣使用非對稱加密，只是簡化了，把非對稱加密只用于校驗文件，而不解決傳輸過程中數據內容泄露的問題，而我們的目的只是防止傳輸過程中數據被篡改，對于數據內容泄露并不是太在意。整個校驗過程如下：

服務端計算出腳本文件的 MD5 值，作為這個文件的數字簽名。

服務端通過私鑰加密第 1 步算出的 MD5 值，得到一個加密后的 MD5 值。

把腳本文件和加密后的 MD5 值一起下發給客戶端。

客戶端拿到加密后的 MD5 值，通過保存在客戶端的公鑰解密。

客戶端計算腳本文件的 MD5 值。

對比第 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平臺 實現了上述回退方案。