前言

最近公司外包給別人做的一個APP專案上線了，拿到原始碼一看那程式碼品質真是一言難盡啊！

剛上線使用者比較少倒也沒出啥問題，不過隨著使用者慢慢變多，問題逐漸暴露出來了。

最嚴重的問題就是我們的APP與伺服器的通訊介面沒有加密處理被人抓包了，有人非法請求我們的介面獲取資料。

怎麼處理這個問題呢？領導又把這個光榮而艱鉅的任務分給了我，沒辦法只能硬著頭皮上啊，經過幾天摸索終於總結出了一套還算安全的APP與服務端通訊的機制。

目錄防非法呼叫——身份認證防抓包——資料加密防重放攻擊——時間戳+隨機字串防篡改——簽名機制完整的Java解決方案防非法呼叫——身份認證

身份認證指只有經過合法授權的使用者才能呼叫我們的介面，這裡我們採用的是Token驗證機制。

APP與服務端的整個通訊過程如下：

使用者首先需要輸入賬號密碼進行登入；APP帶上使用者輸入的賬號密碼請求服務端登入介面；服務端校驗賬號密碼，校驗成功返回一個唯一Token作為使用者身份憑證；APP將Token快取，同時登入成功；使用者使用APP瀏覽資料，APP每次向服務端請求資料時須同時帶上快取的Token；服務端收到請求，首先會校驗Token的合法性，校驗成功正常返回資料，校驗失敗直接返回錯誤；

Token驗證機制解決了什麼問題？

設想一個場景，我們檢測到API介面正在被惡意呼叫，因為所有的介面都必須帶Token才能呼叫，根據Token我們就能快速反查到對應的使用者，所以Token驗證機制可以幫助我們快速確定呼叫者的身份。

發現惡意呼叫，我們通過Token確定呼叫者的身份後可以採取Token失效、封禁帳號等措施來阻止惡意呼叫繼續。

Token驗證機制能防止抓包嗎？

Token驗證機制並不能防止APP被抓包，因為Token同樣存在洩露的風險，惡意呼叫者只需要帶上Token再請求我們的API介面同樣還是能獲取到資料。

因為APP與服務端都是明文通訊，一抓包就能看到請求引數以及返回資料，所以為了防止被抓包我們必須要對資料進行加密處理。

防抓包——資料加密

資料加密的過程，就是對原來明文傳輸的資料按某種加密演算法進行加密處理，使其成為不可讀無意義的密文。

加密演算法大體上可分為對稱加密、非對稱加密和雜湊演算法等幾種方式，後面我們的方案都會涉及到。

對稱加密

對稱加密是一種可逆的加密演算法，其中“對稱”的意思是加密過程和解密過程使用的是同一個金鑰。

常見的對稱加密演算法有DES、3DES、AES、IDEA等。

使用對稱加密演算法一次完整的加解密過程為：

APP與服務端事先約定好對稱加密的金鑰，各自儲存；APP使用金鑰將明文引數加密，再將密文傳送到服務端；服務端收到密文後使用同樣的金鑰對密文進行解密操作得到明文；服務端同樣需要對資料進行加密之後才能返回給APP；

對稱加密演算法的特點

對稱加密演算法的特點是演算法公開、計算量小、加密速度快、加密效率高。對稱加密演算法的安全性依賴於金鑰，任何人只要拿到金鑰就能對資料進行加解密操作。

由於參與通訊的雙方都需要持有金鑰，任何一方的祕鑰洩露，那麼雙方的通訊將無安全性可言，所以怎麼安全的儲存和傳遞金鑰是使用對稱加密最需要關注的問題。

非對稱加密

顧名思義非對稱加密指的是加密過程和解密過程使用不同的金鑰，非對稱加密演算法需要一對金鑰（公鑰和私鑰），公鑰用來加密資料、私鑰用來解密資料。

常見的非對稱加密演算法有RSA、ECC、ElGamal等。

非對稱加密一次完成的加解密過程為：

APP和服務端各自生成一對金鑰對（公鑰和私鑰），公鑰分別給到對方、私鑰自己儲存；APP使用服務端的公鑰對資料進行加密，然後將加密後的密文傳送到服務端；服務端收到密文後使用自己的私鑰進行解密得到明文資料；服務端返回資料同樣需要使用APP的公鑰對資料進行加密；

非對稱加密演算法特點

非對稱加密演算法使用公鑰加密、私鑰解密，私鑰不需要公開傳輸所以安全性較高。同時私鑰可以對資料進行簽名、公鑰可以用來驗證簽名，可以解決中間人攻擊和資訊被篡改的問題。

由於加解密過程使用不同的金鑰，所以對大量資料進行加解密運算的話速度是比較慢的，通常情況下非對稱加密演算法只適合對少量資料進行加解密操作。

對稱加密演算法運算速度快但安全性不足、非對稱加密演算法安全性高但運算速度慢，那麼我們的資料加密方案採用哪種加密演算法呢？

既然兩種加密演算法都有優缺點，那我們可以將兩者結合一下：用對稱加密演算法加解密資料這樣可以保證運算速度，用非對稱加密演算法加密對稱加密演算法的金鑰這樣可以兼顧金鑰的安全性。

防重放攻擊——時間戳+隨機字串

資料加密之後再進行通訊雖然抓包之後看不到明文資料了，但是這並不能阻止不懷好意之人發起重放攻擊。

攔截到請求之後只需再原樣傳送該請求到服務端就可以發起重放攻擊，如果介面內有一些查庫之類的比較耗效能的邏輯，那麼在短時間內發起大量重放攻擊的話將會直接導致服務端崩潰。

怎麼解決這個問題？

道理其實很簡單，我們只需要保證請求只能被正確處理一次即可，這裡我們採用時間戳+隨機字串的解決方案。

時間戳

我們在傳送的資料里加入當前的時間戳，服務端在收到請求資料後首先取出時間戳與伺服器當前時間進行比較，如果兩者相差超過一定時間（比如5分鐘），那麼我們就認為本次請求超時，直接拒絕執行或返回錯誤就可以。

隨機字串

我們在傳送的資料中加入一個隨機生成的字串，服務端在收到請求資料後首先在快取中查詢該字串，如果在快取中找到則認為這是一次重複請求直接拒絕處理，否則將該字串加入快取並繼續執行正確邏輯。

在請求中加入時間戳與隨機字串之後，服務端收到請求後會首先對時間戳和隨機字串進行校驗，校驗通過才會執行正常的業務處理邏輯。

防篡改——數字簽名

為了防重放攻擊，我們在資料中加入了時間戳與隨機字串，但是別人在攔截到我們的請求之後也可以對時間戳和隨機字串進行篡改，面對這種情況服務端要怎麼分辨呢？

為了防止資料在傳輸過程中被篡改，我們引入數字簽名機制。

資訊摘要演算法

資訊摘要演算法（或者叫雜湊演算法）是一種不可逆演算法，任意長度的明文資料經過資訊摘要演算法計算後都可以得出一個固定長度的值（簽名）。

常見的資訊摘要演算法有MD5、SHA-1等。

詳細的簽名過程：

將資料密文、時間戳、隨機字串以及私密的加鹽值一起進行資訊摘要演算法計算得到簽名值；APP將資料密文、時間戳、隨機字串以及簽名值一起發往服務端；服務端收到資料後對資料密文、時間戳、隨機字串以及加鹽值一起進行同樣的資訊摘要演算法計算，將計算出的簽名與資料中籤名進行對比，簽名一致證明沒有沒有被篡改；

為什麼進行資訊摘要計算要“加鹽”？

舉個例子就明白了，比如說123經過MD5計算後的簽名值是abc，那麼就會產生123->abc這樣的對應關係，看到簽名值abc我就能反查到原值為123。如果有人收集並儲存了足夠多的這種對應關係，那麼就有可能從簽名值反推出原值。

這個時候加鹽操作就派上了用場，首先我們生成一個加鹽值qwe，這個加鹽值qwe並不會在網路傳輸，只有通訊雙方自己知道。

我們不直接計算123的簽名值，我們將加鹽值附加到123的後面得到123qwe，接著我們對123qwe進行MD5計算得到一個不一樣的簽名值def。

所以說即使原值一樣，但只要加鹽值不同那麼最後得到簽名值就不一樣，這樣也就無法從簽名值反推出原值了。

完整的Java解決方案

因為我主要搞Java開發，所以就用Java語言實現了一套加解密方案，對稱加密採用AES演算法、非對稱加密採用RSA演算法，資訊摘要演算法採用MD5演算法。

完整程式碼執行流程：

下面分步驟進行詳細介紹：

準備工作：APP與服務端各自生成一對RSA金鑰對（公鑰和私鑰），公鑰給到對方、私鑰各自私密儲存；

APP傳送加密資料流程

1、生成一個隨機的AES演算法金鑰；

2、使用服務端的RSA公鑰對AES金鑰明文進行加密得到AES金鑰密文；

3、對引數明文進行AES加密得到引數密文；

4、生成當前請求時間的時間戳；

5、為該次請求生成一個隨機字串；

6、將引數密文、時間戳、隨機字串和AES金鑰密文進行MD5計算得到md5值；

7、使用APP自己的RSA私鑰對md5值進行簽名得到簽名值；

8、將引數密文、時間戳、隨機字串、AES金鑰密文和簽名值一起傳送到服務端；

服務端解密資料流程

1、校驗時間戳與伺服器當前時間的差值是否在合理的區間，超過則認為該次請求超時；

2、校驗隨機字串是否已經在快取中，如果已經在快取中說明該次請求為重複請求，否則將該字串加入快取；

3、從收到的資料中取出引數密文、時間戳、隨機字串和AES金鑰密文進行MD5計算得到md5值；

4、使用APP的RSA公鑰對計算得到的md5值和請求資料中的簽名值進行驗證，簽名驗證通過則說明請求資料沒有被篡改；

5、服務端使用自己的RSA私鑰解密AES金鑰密文得到AES金鑰明文；

6、使用AES金鑰明文對引數密文進行AES解密操作得到引數明文；

7、拿到引數明文之後進行正常的業務處理邏輯；

8、服務端資料需要經過同樣的加密操作之後才能返回給APP；

總結

APP與服務端肯定是要使用HTTPS協議進行通訊的，再搭配上RAS+AES混合加密演算法以及數字簽名機制，相信這套方案在絕大部分情況下是可以保證通訊及資料安全的。

當然了，不排除APP有被人破解的可能，這種情況下任何加密機制都是白搭。但是不能說我們的加密機制就沒用了，我們只需要將破解我們APP的成本提高到一定程度就可以了。

這個道理其實就跟門鎖一樣，市面上絕大部分門鎖只要有時間都可以被開鎖的人開啟，那你能說門鎖就沒有存在的意義了嗎？

“分享知識，收穫快樂”