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