使用 jspatch 有兩個安全問題：
傳輸安全：js 指令碼可以呼叫任意 oc 方法，許可權非常大，若被中間人攻擊替換**，會造成較大的危害。
接下來說下這兩個問題的解決方案。
若要讓 js **傳輸過程中不輕易被中間人截獲替換，很容易想到的方式就是對**進行加密，可以用 zip 的加密壓縮，也可以用 aes 等加密演算法。這個方案的優點是非常簡單，缺點是安全性低，容易被破解。因為金鑰是要儲存在客戶端的，只要客戶端被人拿去反編譯，把密碼欄位找出來，就完成破解了。
對此也有一些改進方案，例如：
2.給每個使用者下發不同的金鑰。但這樣就非常繁瑣，需要對下發金鑰的請求做好保護，後台需要每次都對指令碼進行不同金鑰的加密操作，複雜性高了。
綜上，對稱加密安全性低，若要稍微提高點安全性，就會提公升程式複雜度。
第二個方案是直接使用 https 傳輸，優點是安全性高，只要使用正確，證書在服務端未洩露，就不會被破解。缺點是部署麻煩，需要使用者伺服器支援 https，門檻較高。另外客戶端需要做好 https 的證書驗證（有些使用者可能會漏掉這個驗證，導致安全性大降），具體的認證方式可見網上一些文章，例如這篇。如果伺服器本來就支援 https，使用這種方案也是一種不錯的選擇。
有沒有安全性高，部署簡單，門檻低的方案？rsa 校驗就是。
這種方式其實原理跟 https 是一樣的，同樣使用非對稱加密，只是簡化了，把非對稱加密只用於校驗檔案，而不解決傳輸過程中資料內容洩露的問題，而我們的目的只是防止傳輸過程中資料被篡改，對於資料內容洩露並不是太在意。整個校驗過程如下：
服務端計算出指令碼檔案的 md5 值，作為這個檔案的數字簽名。
服務端通過私鑰加密第 1 步算出的 md5 值，得到乙個加密後的 md5 值。
把指令碼檔案和加密後的 md5 值一起下發給客戶端。
客戶端拿到加密後的 md5 值，通過儲存在客戶端的公鑰解密。
客戶端計算指令碼檔案的 md5 值。
對比第 4/5 步的兩個 md5 值（分別是客戶端和服務端計算出來的 md5 值），若相等則通過校驗。
只要通過校驗，就能確保指令碼在傳輸的過程中沒有被篡改，因為第三方若要篡改指令碼檔案，必須計算出新的指令碼檔案 md5 並用私鑰加密，客戶端公鑰才能解密出這個 md5 值，而在服務端未洩露的情況下第三方是拿不到私鑰的。
這種方案安全性跟 https 一致，但不像 https 一樣部署麻煩，一套**即可通用。對於它的缺點：資料內容洩露，其實在傳輸過程中不洩露，儲存在本地同樣會洩露，若對此在意，可以對指令碼檔案再加一層簡單的對稱加密。這個方案優點多缺點少，推薦使用，目前 jspatch平台 就是使用這個方案。
最後有個小問題，儲存在客戶端的**也可能被人篡改，需不需要採取措施？這個要看各人需求了，因為這個安全問題不大，能篡改本地檔案，差不多已經有手機所有許可權了，這時也無所謂指令碼會不會被篡改了。若有需要，可以加個簡單的對稱加密。
JSPatch 部署安全策略
傳輸安全 js 指令碼可以呼叫任意 oc 方法，許可權非常大，若被中間人攻擊替換 會造成較大的危害。接下來說下這兩個問題的解決方案。若要讓 js 傳輸過程中不輕易被中間人截獲替換，很容易想到的方式就是對 進行加密，可以用 zip 的加密壓縮，也可以用 aes 等加密演算法。這個方案的優點是非常簡單，...
MySQL安全策略
資料是企業核心資產，資料對企業而言是最重要的工作之一。稍有不慎，極有可能發生資料無意洩露，甚至被黑客惡意竊取的風險。每年業界都會傳出幾起大事件，某知名或不知名的公司被脫褲 拖庫的諧音，意思是整個資料庫被黑客盜取 之類的。從資料安全上也可以分為外網安全及內部操作安全，下面分別討論一下。內部操作安全策略...
SSH安全策略
ssh安全策略 ss配置基本安全策略 調整sshd服務配置，並過載服務 root vim etc ssh sshd config protocol 2 去掉ssh協議v1 permitrootlogin no 禁止root使用者登入 permitemptypasswords no 禁止密碼為空的使用...