服務端通訊安全攻防詳解

接著，昨天《https原理剖析與專案場景》的話題，我覺得安全方面有蠻多話題可以聊聊的，那麼今天再分享一篇《服務端通訊安全攻防詳解》。

服務端介面通訊過程中，一般是明文傳輸的，沒有經過任何安全處理。那麼這個時候就很容易在傳輸過程中被中間者竊聽、篡改、冒充等風險。因此，對於敏感資訊，以及重要檔案就需要進行加密策略，保證通訊的安全性。

base64是網路上最常見的用於傳輸8bit位元組**的編碼方式之一，但是它其實並不是一種用於安全領域的加密解密演算法。

但是，base64編碼的資料並不會被人用肉眼所直觀的理解，所以也有人使用base64來進行加密解密，這裡所說的加密與解密實際是指編碼和解碼的過程。

這種，加密傳輸的安全性是非常低的，base64加密非常容易被人識別並解碼。

des也是一種非常常用的加密方案，我們會將敏感的資訊在通訊過程中通過des進行加密傳輸，然後在客戶端和服務端直接進行解碼。

此時，作為讀者的你，可能會有個疑問，那如何保管金鑰呢？其實，想想，答案就復出水面了，因為客戶端和服務端都需要進行解碼，所以兩者都要存乙份金鑰。其實，還有一種方案是通過服務端下發，但是下發的時候通訊的安全性也是沒有很好的保障。

aes和des類似，相較於des演算法而言，aes演算法有著更高的速度和資源使用效率，安全級別也較之更高。一般情況下，用於檔案的加密。我們之前做個不準確測試，aes和des分別對乙個大檔案加密，aes的速度大概是des的5倍。（因為基於工具和環境問題，這個資料不是很準確喲）。

仍然存在乙個相同的問題：金鑰可能會洩漏。因此，保管好金鑰很關鍵。

這個可以參考上篇部落格《https原理剖析與專案場景》的內容。

https的價值在於：

這個方案，沒法保護敏感資料，如果需要對敏感資料進行加密，還是需要考慮加密方案。

基於oauth2協議，進行url簽名。這個方案，有很多話題可以分享，後面另開一篇來詳細講解。

值得注意的是，url簽名只能垂直許可權管理，但沒法保護敏感資料，如果需要對敏感資料進行保護，還是需要考慮加密方案。

rsa雙向認證，就是用對方的公鑰加密是為了保密，這個只有對方用私鑰能解密。用自己的私鑰加密是為了防抵賴，能用我的公鑰解開，說明這是我發來的。

例如，支付寶的支付介面就是非常典型的rsa雙向認證的安全方案。此外，我們之前的教育資源、敏感驗證碼出於安全性考慮都借鑑了這個方案。