最近公司需要通過公網與其它平台完成接口對接，但是基於開發時間和其它因素的考慮，本次對接無法采用https協議實現。既然不能用https協議，那就退而求其次采用http協議吧！
那么問題來了！在對接的過程中我們需要對如下問題進行相關的考慮：
1、敏感信息的不可見性
使用http協議傳輸數據很容易被抓包監聽傳輸內容，如果這些數據中存在敏感信息的話，風險太大了。因此我們需要對我們的傳輸數據進行一定的加密處理，即使數據被預期接收方之外的其它不法分子攔截，也無法輕易的破譯此次請求的傳輸內容！最簡單的方案就是對傳輸數據使用Base64方法轉碼，使得數據具備一定的不可讀性。當然啦，這種方案實際上是不可取的，因為Base64方案太容易被識別然后解密了。比較常見的做法是，發送方和接收方彼此約定密鑰，發送方發送時用密鑰對數據加密，接收方用密鑰對數據解密。比如AES128加密算法？但是AES128加密也存在局限性，需要定期維護。就算你認為你這方的內部人員是可信的，你也無法無法保證對方的密鑰不會泄漏吧。當然聰明的你可能會說，那我就使用非對稱加密算法，比如RSA好了。好像是沒啥問題？但是如果數據量比較大的話，RSA加密方法對服務器的壓力也是很大的。。所以本次結合了AES和RSA來實現我們的數據傳輸。
2、防止數據被篡改
用簽名！用簽名！用簽名！重要的事情說三遍？例如：當數據被封裝好后，我們可以用md5算法計算出待傳輸數據的摘要字符串作為簽名。當服務器接受到數據后，同樣使用md5對數據做摘要，同請求報文中的簽名作比較，若不一致則說明該http請求數據已被篡改。但僅僅使用md5對數據作摘要就夠了嗎？萬一攻擊方發現了數據簽名是用md5做的，攻擊方只需要對已篡改的數據再做一次md5，同時更新請求中的簽名即可。因此如何生成可靠的簽名也需要我們仔細的斟酌。有幾點我覺得是需要注意的：1、無法輕易的根據簽名推反推出當前簽名所采用的算法；2、簽名算法的復雜性、可靠性；3、不要直接對傳輸數據作簽名，可以先對請求數據作摘要，再使用加密算法生成簽名，既可以提升效率也在一定程度上提高了安全性。
3、http請求的真實性
有很多方案可以保證http請求的真實性。比如使用token來進行身份驗證，可以借鑒微信的身份驗證方案或者jwt實現。本次我們只做了簡單的處理，在http請求頭中設置了一個時間戳，當服務器接收到數據后，會取出http請求中的時間戳，同時與服務器當前時間作比較。若時間間隔過大，則認為該請求是不真實的，直接拒絕並返回！
上面簡單的介紹了http傳輸敏感數據需要注意的地方，本方案具體實現思路如下圖所示：
發送方需要干的事
1、生成簽名
- 構造傳輸對象，並將傳輸對象轉換成json字符串
本次接口傳輸采用rest模式作為標准，先構造待傳輸對象。構造完成后借用Google的Gson包來將對象轉換成json字符串。
- 使用md5算法生成json字符串摘要
- 使用RSA公鑰對摘要字符串作加密處理，生成簽名
2、加密請求報文
發送方創建一個http請求時，需要動態的生成一個AESKey，同時使用該AESKey對請求數據作加密處理。為什么每次請求都需要生成一個新的AESKey呢？主要還是為了防止數據泄漏。如果固定使用相同的Key，萬一Key被發送方內部人員泄漏了，其實也對發送數據的加密也就沒有意義了。
3、加密AES密鑰
在http請求傳遞數據時，AES密鑰也會被同樣傳遞過去。為了保證AES密鑰的安全性，我們采用RSA公鑰對AES密鑰作加密處理。處理完后會放到Http請求頭的Authencation字段中。
4、構造http請求
- 將第一步生成的簽名放到http請求頭中的Authencation字段中
- 將加密后的AES密鑰放到http請求頭中的SecurityKey字段中
- 將該請求創建時間放到http請求頭中的TimesTamp字段中
- 將第二步生成的加密報文放到http body中
5、處理http請求結果
在此之前，請求方和發送方需要約定返回結果的加密方式。發送方接收到http請求返回結果后，通過約定的方式對返回結果進行處理，以供后續使用。這里我們僅簡單的約定接收方使用接收到的AES密鑰對返回數據作加密后返回即可。
接收方需要干的事
1、請求的真實性校驗
獲取http請求頭中的TimesTamp字段，同時與系統時間作比較。如果請求時間與當前系統時間間隔在五分鍾之內，則認為請求是真實的，反之則認為請求是非法的。
2、獲取AES密鑰
從http請求中的SecurtiyKey獲取被加密的AES密鑰，使用RSA密鑰對其解密，獲取可供使用的AES密鑰
3、獲取請求報文
從httpbody中獲取請求報文，使用上面第二步生成的AES密鑰解密請求報文
4、驗簽
- 對第三步生成的請求報文作md5摘要生成md5Str
- 獲取http請求頭中的Authencation字符串，接着使用接收方保存的RSA密鑰對其作解密處理獲取rsaDecryptStr
- 比較md5Str和rsaDecryptStr是否一致，若一致則驗簽通過
5、業務處理
使用第三步得到的請求報文進行業務處理
6、返回處理結果
使用第二步獲取到的AES密鑰對返回結果作加密處理並返回
總結
本次http請求傳輸敏感數據方案的實現，上面做了詳細的介紹。另外多提一下。在接收方進行驗簽的時候，我們可以定義一個過濾器來過濾指定http請求。在過濾器中完成驗簽的工作，以避免在業務處理代碼中摻雜驗簽代碼！同時使用過濾器也可以對請求返回結果進行加工處理，在這里就是用AES密鑰加密返回結果啦！
出處：http://www.cnblogs.com/cfyrwang/p/8215512.html