本分享自公眾號-猿天地，作者為尹吉歡
一、前言
前後端分離的開發方式，我們以接口為標準來進行推動，定義好接口，各自開發自己的功能，最後進行聯調整合。無論是開發原生的APP還是webapp還是PC端的軟件,只要是前後端分離的模式，就避免不了調用後端提供的接口來進行業務交互。
網頁或者app，只要抓下包就可以清楚的知道這個請求獲取到的數據，這樣的接口對爬蟲工程師來說是一種福音，要抓你的數據簡直輕而易舉。
數據的安全性非常重要，特別是用戶相關的信息，稍有不慎就會被不法分子盜用，所以我們對這塊要非常重視，容不得馬虎。
二、如何保證API調用時數據的安全性？
1、通信使用https
2、請求籤名，防止參數被篡改
3、身份確認機制，每次請求都要驗證是否合法
4、APP中使用ssl pinning防止抓包操作
5、對所有請求和響應都進行加解密操作
6、等等方案…….
三、對所有請求和響應都進行加解密操作
方案有很多種，當你做的越多，也就意味著安全性更高，今天我跟大家來介紹一下對所有請求和響應都進行加解密操作的方案，即使能抓包，即使能調用我的接口，但是我返回的數據是加密的，只要加密算法夠安全，你得到了我的加密內容也對我沒什麼影響。
像這種工作最好做成統一處理的，你不能讓每個開發都去關注這件事情，如果讓每個開發去關注這件事情就很麻煩了，返回數據時還得手動調用下加密的方法，接收數據後還得調用下解密的方法。
為此，我基於Spring Boot封裝了一個Starter, 內置了AES加密算法。GitHub地址如下：
https://github.com/yinjihuan/spring-boot-starter-encrypt
先來看看怎麼使用，可以下載源碼，然後引入即可，然後在啟動類上增加@EnableEncrypt註解開啟加解密操作：
增加加密的key配置：
- spring.encrypt.key：加密key，必須是16位
- spring.encrypt.debug：是否開啟調試模式,默認為false,如果為true則不啟用加解密操作
為了考慮通用性，不會對所有請求都執行加解密，基於註解來做控制
響應數據需要加密的話，就在Controller的方法上加@Encrypt註解即可。
當我們訪問/list接口時，返回的數據就是加密之後base64編碼的格式。
還有一種操作就是前段提交的數據，分為2種情況，一種是get請求，這種暫時沒處理，後面再考慮，目前只處理的post請求，基於json格式提交的方式，也就是說後臺需要用@RequestBody接收數據才行, 需要解密的操作我們加上@Decrypt註解即可。
加了@Decrypt註解後，前端提交的數據需要按照AES加密算法，進行加密，然後提交到後端，後端這邊會自動解密，然後再映射到參數對象中。
上面講解的都是後端的代碼，前端使用的話我們以js來講解，當然你也能用別的語言來做，如果是原生的安卓app也是用java代碼來處理。
前端需要做的就2件事情：
1、統一處理數據的響應，在渲染到頁面之前進行解密操作
2、當有POST請求的數據發出時，統一加密
js加密文件請參考我GitHub中encrypt中的aes.js,crypto-js.js,pad-zeropadding.js
我們以axios來作為請求數據的框架，用axios的攔截器來統一處理加密解密操作
首先還是要封裝一個js加解密的類，需要注意的是加密的key需要和後臺的對上，不然無法相互解密，代碼如下：
axios攔截器中統一處理代碼：
到此為止，我們就為整個前後端交互的通信做了一個加密的操作，只要加密的key不洩露，別人得到你的數據也沒用，問題是如何保證key不洩露呢？
服務端的安全性較高，可以存儲在數據庫中或者配置文件中，畢竟在我們自己的服務器上，最危險的其實就時前端了，app還好，可以打包，但是要防止反編譯等等問題。
如果是webapp則可以依賴於js加密來實現，下面我給大家介紹一種動態獲取加密key的方式，只不過實現起來比較複雜，我們不上代碼，只講思路：
加密算法有對稱加密和非對稱加密，AES是對稱加密，RSA是非對稱加密。之所以用AES加密數據是因為效率高，RSA運行速度慢,可以用於簽名操作。
我們可以用這2種算法互補，來保證安全性，用RSA來加密傳輸AES的秘鑰，用AES來加密數據，兩者相互結合，優勢互補。
其實大家理解了HTTPS的原理的話對於下面的內容應該是一看就懂的，HTTPS比HTTP慢的原因都是因為需要讓客戶端與服務器端安全地協商出一個對稱加密算法。剩下的就是通信時雙方使用這個對稱加密算法進行加密解密。
1、客戶端啟動，發送請求到服務端，服務端用RSA算法生成一對公鑰和私鑰，我們簡稱為pubkey1,prikey1，將公鑰pubkey1返回給客戶端。
2、客戶端拿到服務端返回的公鑰pubkey1後，自己用RSA算法生成一對公鑰和私鑰，我們簡稱為pubkey2,prikey2，並將公鑰pubkey2通過公鑰pubkey1加密，加密之後傳輸給服務端。
3、此時服務端收到客戶端傳輸的密文，用私鑰prikey1進行解密，因為數據是用公鑰pubkey1加密的，通過解密就可以得到客戶端生成的公鑰pubkey2
4、然後自己在生成對稱加密，也就是我們的AES,其實也就是相對於我們配置中的那個16的長度的加密key,生成了這個key之後我們就用公鑰pubkey2進行加密，返回給客戶端，因為只有客戶端有pubkey2對應的私鑰prikey2，只有客戶端才能解密，客戶端得到數據之後，用prikey2進行解密操作，得到AES的加密key,最後就用加密key進行數據傳輸的加密，至此整個流程結束。
四、spring-boot-starter-encrypt原理
最後我們來簡單的介紹下spring-boot-starter-encrypt的原理吧，也讓大家能夠理解為什麼Spring Boot這麼方便，只需要簡單的配置一下就可以實現很多功能。
啟動類上的@EnableEncrypt註解是用來開啟功能的,通過@Import導入自動配置類
EncryptAutoConfiguration中配置請求和響應的處理類，用的是Spring中的RequestBodyAdvice和ResponseBodyAdvice，在Spring中對請求進行統計處理比較方便。如果還要更底層去封裝那就要從servlet那塊去處理了。
通過RequestBodyAdvice和ResponseBodyAdvice就可以對請求響應做處理了，大概的原理就是這麼多了。
閱讀更多 牛旦教育IT課堂 的文章
