學(xué)習(xí)完整課程請移步 互聯(lián)網(wǎng) Java 全棧工程師

服務(wù)端接口通信過程中，一般是明文傳輸?shù)模瑳]有經(jīng)過任何安全處理。那么這個時候就很容易在傳輸過程中被中間者竊聽、篡改、冒充等風(fēng)險。因此，對于敏感信息，以及重要文件就需要進(jìn)行加密策略，保證通信的安全性。

Base64 加密傳輸

Base64 是網(wǎng)絡(luò)上最常見的用于傳輸 8Bit 字節(jié)代碼的編碼方式之一，但是它其實并不是一種用于安全領(lǐng)域的加密解密算法。

但是，Base64 編碼的數(shù)據(jù)并不會被人用肉眼所直觀的理解，所以也有人使用 Base64 來進(jìn)行加密解密，這里所說的加密與解密實際是指編碼和解碼的過程。

這種，加密傳輸?shù)陌踩允欠浅５偷?，Base64 加密非常容易被人識別并解碼。

DES 對稱加密

DES 也是一種非常常用的加密方案，我們會將敏感的信息在通信過程中通過DES進(jìn)行加密傳輸，然后在客戶端和服務(wù)端直接進(jìn)行解碼。

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

所以，DES 對稱加密也是存在一定的安全隱患：密鑰可能會泄漏。這邊，舉個真實的案例，某個 APP 的資源不錯，同事想抓包分析下其服務(wù)端通信的信息結(jié)構(gòu)，但是發(fā)現(xiàn)它既然全部采用了 DES 加密方案，本來想放棄了，但是我們又回頭想想客戶端肯定需要密鑰對接口的加密的內(nèi)容做解碼才能正常展現(xiàn)，那么密鑰肯定在 APP 包中，因此我們又對 APP 進(jìn)行了反編譯，結(jié)果成功的獲取到了密鑰，對服務(wù)端通信的加密信息進(jìn)行了解碼。

AES 對稱加密

AES 和 DES 類似，相較于 DES 算法而言，AES 算法有著更高的速度和資源使用效率，安全級別也較之更高。一般情況下，用于文件的加密。我們之前做個不準(zhǔn)確測試，AES 和 DES 分別對一個大文件加密，AES 的速度大概是 DES 的 5 倍。（因為基于工具和環(huán)境問題，這個數(shù)據(jù)不是很準(zhǔn)確喲）。

仍然存在一個相同的問題：密鑰可能會泄漏。因此，保管好密鑰很關(guān)鍵。

升級到 HTTPS

HTTPS 的價值在于：

• 內(nèi)容加密，第三方無法竊聽。
• 身份認(rèn)證，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。
• 數(shù)據(jù)完整性。防止內(nèi)容冒充或者篡改。

這個方案，沒法保護(hù)敏感數(shù)據(jù)，如果需要對敏感數(shù)據(jù)進(jìn)行加密，還是需要考慮加密方案。

URL 簽名

基于 OAuth2 協(xié)議，進(jìn)行 URL 簽名。這個方案，有很多話題可以分享，后面另開一篇來詳細(xì)講解。

值得注意的是，URL 簽名只能垂直權(quán)限管理，但沒法保護(hù)敏感數(shù)據(jù)，如果需要對敏感數(shù)據(jù)進(jìn)行保護(hù)，還是需要考慮加密方案。

雙向 RSA 加密

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

例如，支付寶的支付接口就是非常典型的 RSA 雙向認(rèn)證的安全方案。此外，我們之前的教育資源、敏感驗證碼出于安全性考慮都借鑒了這個方案。