你的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
- 資料被抓包竊取
- 資料被調包篡改
- 資料被爬取洩露
資料加密
- 對稱加密：DES、AES
- 非對稱加密：RSA
安全夠了嗎，還有哪些要做？
加密解決了資料上行的安全，然而黑客，直接抓密文來提交，怎麼辦？
介面簽名
介面簽名夠了嗎，還有哪些要做？
介面簽名，僅僅依靠引數順序的排列組合，安全強度不夠
身份認證-----token令牌
Token授權機制：使用者使用使用者名稱密碼登陸後，伺服器給客戶端返回一個Token，並在伺服器中快取此Token。後續伺服器收到請求後進行Token驗證，若Token不存在，則說明請求無效
身份認證的封裝-----cookie隱式攜帶token
- 使用tokenFilter統一處理
- 登陸成功，伺服器直接種token到cookie中
- 客戶端請求時，需要送token值的加密串，到伺服器
總結
安全是一個永恆的話題，隨著各大網站全站https的推進，安全也越來越被重視。簽名設計大家必須有，HTTPS希望大家有。
歡迎大家一起交流，喜歡文章記得點個贊喲，感謝支援！