你的API還在裸奔？一文講解API攻防安全設計問題

前言

看起來好像先後端分離是個浪潮，原來只有APP客戶端會考慮這些，如今連Web都要考慮先後端分離 。這裏面不得不談的就是API的設計和安全性，這些個問題不解決好，將會給服務器安全和性能帶來很大威脅 。下面我也是根據本身的一些經歷和經驗說下本身的一些心得 。

API的設計中，主要考慮兩大方面的問題 ：

• 防止API被惡意調用
• API通訊中數據加密的問題

接口的安全性主要圍繞token、timestamp和sign三個機制展開設計，保證接口的數據不會被篡改和重複調用，下面具體來看：

Token受權機制：

用戶使用用戶名密碼登陸後服務器給客戶端返回一個Token（一般是UUID），並將Token-UserId以鍵值對的形式存放在緩存服務器中。服務端接收到請求後進行Token驗證，若是Token不存在，說明請求無效。Token是客戶端訪問服務端的憑證。

時間戳超時機制：

用戶每次請求都帶上當前時間的時間戳timestamp，服務端接收到timestamp後跟當前時間進行比對，若是時間差大於必定時間（好比5分鐘），則認爲該請求失效。時間戳超時機制是防護DOS攻擊的有效手段。

簽名機制：

將 Token 和 時間戳 加上其餘請求參數再用MD5或SHA-1算法（可根據狀況加點鹽）加密，加密後的數據就是本次請求的簽名sign，服務端接收到請求後以一樣的算法獲得簽名，並跟當前的簽名進行比對，若是不同，說明參數被更改過，直接返回錯誤標識。簽名機制保證了數據不會被篡改。

因此你的API還在裸奔？

Api有哪些安全問題？----http接口—先後端分離mvvm

1. 數據被抓包竊取
2. 數據被調包篡改
3. 數據被爬取泄露

數據加密

1. 對稱加密：DES、AES
2. 非對稱加密：RSA

安全夠了嗎，還有哪些要作？

加密解決了數據上行的安全，然而黑客，直接抓密文來提交，怎麼辦？

接口簽名

接口簽名夠了嗎，還有哪些要作？

接口簽名，僅僅依靠參數順序的排列組合，安全強度不夠

身份認證-----token令牌

Token受權機制：用戶使用用戶名密碼登錄後，服務器給客戶端返回一個Token，並在服務器中緩存此Token。後續服務器收到請求後進行Token驗證，若Token不存在，則說明請求無效

身份認證的封裝-----cookie隱式攜帶token

1. 使用tokenFilter統一處理
2. 登錄成功，服務器直接種token到cookie中
3. 客戶端請求時，須要送token值的加密串，到服務器

總結

安全是一個永恆的話題，隨着各大網站全站https的推動，安全也愈來愈被重視。簽名設計你們必須有，HTTPS但願你們有。

歡迎你們一塊兒交流，喜歡文章記得點個贊喲，感謝支持！