一種基於http協議的敏感數據傳輸方案

最近公司須要經過公網與其它平臺完成接口對接，可是基於開發時間和其它因素的考慮，本次對接沒法採用https協議實現。既然不能用https協議，那就退而求其次採用http協議吧！

那麼問題來了！在對接的過程當中咱們須要對以下問題進行相關的考慮：

一、敏感信息的不可見性

　　使用http協議傳輸數據很容易被抓包監聽傳輸內容，若是這些數據中存在敏感信息的話，風險太大了。所以咱們須要對咱們的傳輸數據進行必定的加密處理，即便數據被預期接收方以外的其它不法分子攔截，也沒法輕易的破譯這次請求的傳輸內容！最簡單的方案就是對傳輸數據使用Base64方法轉碼，使得數據具有必定的不可讀性。固然啦，這種方案其實是不可取的，由於Base64方案太容易被識別而後解密了。比較常見的作法是，發送方和接收方彼此約定密鑰，發送方發送時用密鑰對數據加密，接收方用密鑰對數據解密。好比AES128加密算法？可是AES128加密也存在侷限性，須要按期維護。就算你認爲你這方的內部人員是可信的，你也沒法沒法保證對方的密鑰不會泄漏吧。固然聰明的你可能會說，那我就使用非對稱加密算法，好比RSA好了。好像是沒啥問題？可是若是數據量比較大的話，RSA加密方法對服務器的壓力也是很大的。。因此本次結合了AES和RSA來實現咱們的數據傳輸。

二、防止數據被篡改

　　用簽名！用簽名！用簽名！重要的事情說三遍？例如：當數據被封裝好後，咱們能夠用md5算法計算出待傳輸數據的摘要字符串做爲簽名。當服務器接受到數據後，一樣使用md5對數據作摘要，同請求報文中的簽名做比較，若不一致則說明該http請求數據已被篡改。但僅僅使用md5對數據做摘要就夠了嗎？萬一攻擊方發現了數據簽名是用md5作的，攻擊方只須要對已篡改的數據再作一次md5，同時更新請求中的簽名便可。所以如何生成可靠的簽名也須要咱們仔細的斟酌。有幾點我以爲是須要注意的：一、沒法輕易的根據簽名推反推出當前簽名所採用的算法；二、簽名算法的複雜性、可靠性；三、不要直接對傳輸數據做簽名，能夠先對請求數據做摘要，再使用加密算法生成簽名，既能夠提高效率也在必定程度上提升了安全性。

三、http請求的真實性

　　有不少方案能夠保證http請求的真實性。好比使用token來進行身份驗證，能夠借鑑微信的身份驗證方案或者jwt實現。本次咱們只作了簡單的處理，在http請求頭中設置了一個時間戳，當服務器接收到數據後，會取出http請求中的時間戳，同時與服務器當前時間做比較。若時間間隔過大，則認爲該請求是不真實的，直接拒絕並返回！

上面簡單的介紹了http傳輸敏感數據須要注意的地方，本方案具體實現思路以下圖所示：

發送方須要乾的事

一、生成簽名

• 構造傳輸對象，並將傳輸對象轉換成json字符串

　　　　 本次接口傳輸採用rest模式做爲標準，先構造待傳輸對象。構造完成後借用Google的Gson包來將對象轉換成json字符串。

• 使用md5算法生成json字符串摘要
• 使用RSA公鑰對摘要字符串做加密處理，生成簽名

二、加密請求報文
　　發送方建立一個http請求時，須要動態的生成一個AESKey，同時使用該AESKey對請求數據做加密處理。爲何每次請求都須要生成一個新的AESKey呢？主要仍是爲了防止數據泄漏。若是固定使用相同的Key，萬一Key被髮送方內部人員泄漏了，其實也對發送數據的加密也就沒有意義了。

三、加密AES密鑰
　　在http請求傳遞數據時，AES密鑰也會被一樣傳遞過去。爲了保證AES密鑰的安全性，咱們採用RSA公鑰對AES密鑰做加密處理。處理完後會放到Http請求頭的Authencation字段中。

四、構造http請求

• 將第一步生成的簽名放到http請求頭中的Authencation字段中
• 將加密後的AES密鑰放到http請求頭中的SecurityKey字段中
• 將該請求建立時間放到http請求頭中的TimesTamp字段中
• 將第二步生成的加密報文放到http body中

五、處理http請求結果
　　在此以前，請求方和發送方須要約定返回結果的加密方式。發送方接收到http請求返回結果後，經過約定的方式對返回結果進行處理，以供後續使用。這裏咱們僅簡單的約定接收方使用接收到的AES密鑰對返回數據做加密後返回便可。

接收方須要乾的事

一、請求的真實性校驗
　　獲取http請求頭中的TimesTamp字段，同時與系統時間做比較。若是請求時間與當前系統時間間隔在五分鐘以內，則認爲請求是真實的，反之則認爲請求是非法的。

二、獲取AES密鑰
　　從http請求中的SecurtiyKey獲取被加密的AES密鑰，使用RSA密鑰對其解密，獲取可供使用的AES密鑰

三、獲取請求報文
　　從httpbody中獲取請求報文，使用上面第二步生成的AES密鑰解密請求報文

四、驗籤

• 對第三步生成的請求報文做md5摘要生成md5Str
• 獲取http請求頭中的Authencation字符串，接着使用接收方保存的RSA密鑰對其做解密處理獲取rsaDecryptStr
• 比較md5Str和rsaDecryptStr是否一致，若一致則驗籤經過

五、業務處理
　　使用第三步獲得的請求報文進行業務處理

六、返回處理結果
　　使用第二步獲取到的AES密鑰對返回結果做加密處理並返回

總結　　本次http請求傳輸敏感數據方案的實現，上面作了詳細的介紹。另外多提一下。在接收方進行驗籤的時候，咱們能夠定義一個過濾器來過濾指定http請求。在過濾器中完成驗籤的工做，以免在業務處理代碼中摻雜驗籤代碼！同時使用過濾器也能夠對請求返回結果進行加工處理，在這裏就是用AES密鑰加密返回結果啦！