API接口安全性設計

摘自：https://blog.csdn.net/qq_21441663/article/details/83473959

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

Token受權機制：

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

時間戳超時機制：

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

簽名機制：

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

拒絕重複調用（非必須）：

客戶端第一次訪問時，將簽名sign存放到緩存服務器中，超時時間設定爲跟時間戳的超時時間一致，兩者時間一致能夠保證不管在timestamp限定時間內仍是外 URL都只能訪問一次。若是有人使用同一個URL再次訪問，若是發現緩存服務器中已經存在了本次簽名，則拒絕服務。若是在緩存中的簽名失效的狀況下，有人使用同一個URL再次訪問，則會被時間戳超時機制攔截。這就是爲何要求時間戳的超時時間要設定爲跟時間戳的超時時間一致。拒絕重複調用機制確保URL被別人截獲了也沒法使用（如抓取數據）。

流程以下：

• 客戶端經過用戶名密碼登陸服務器並獲取Token

• 客戶端生成時間戳timestamp，並將timestamp做爲其中一個參數。

• 客戶端將全部的參數，包括Token和timestamp按照本身的算法進行排序加密獲得簽名sign

• 將token、timestamp和sign做爲請求時必須攜帶的參數加在每一個請求的URL後邊（http://api.com/users?token=asdsadasd&timestamp=123&sign=123123123）

• 服務端寫一個過濾器對token、timestamp和sign進行驗證，只有在token有效、timestamp未超時、緩存服務器中不存在sign三種狀況同時知足，本次請求才有效

在以上三中機制的保護下，

若是有人劫持了請求，並對請求中的參數進行了修改，簽名就沒法經過；

若是有人使用已經劫持的URL進行DOS攻擊，服務器則會由於緩存服務器中已經存在簽名或時間戳超時而拒絕服務，因此DOS攻擊也是不可能的；

若是簽名算法和用戶名密碼都暴露了，那齊天大聖來了估計也很差使吧。。。。

最後說一句，全部的安全措施都用上的話有時候不免太過複雜，在實際項目中須要根據自身狀況做出裁剪，好比能夠只使用簽名機制就能夠保證信息不會被篡改，或者定向提供服務的時候只用Token機制就能夠了。如何裁剪，全看項目實際狀況和對接口安全性的要求~

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

Token受權機制：

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

時間戳超時機制：

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

簽名機制：

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

拒絕重複調用（非必須）：

客戶端第一次訪問時，將簽名sign存放到緩存服務器中，超時時間設定爲跟時間戳的超時時間一致，兩者時間一致能夠保證不管在timestamp限定時間內仍是外 URL都只能訪問一次。若是有人使用同一個URL再次訪問，若是發現緩存服務器中已經存在了本次簽名，則拒絕服務。若是在緩存中的簽名失效的狀況下，有人使用同一個URL再次訪問，則會被時間戳超時機制攔截。這就是爲何要求時間戳的超時時間要設定爲跟時間戳的超時時間一致。拒絕重複調用機制確保URL被別人截獲了也沒法使用（如抓取數據）。

流程以下：

• 客戶端經過用戶名密碼登陸服務器並獲取Token

• 客戶端生成時間戳timestamp，並將timestamp做爲其中一個參數。

• 客戶端將全部的參數，包括Token和timestamp按照本身的算法進行排序加密獲得簽名sign

• 將token、timestamp和sign做爲請求時必須攜帶的參數加在每一個請求的URL後邊（http://api.com/users?token=asdsadasd&timestamp=123&sign=123123123）

• 服務端寫一個過濾器對token、timestamp和sign進行驗證，只有在token有效、timestamp未超時、緩存服務器中不存在sign三種狀況同時知足，本次請求才有效

在以上三中機制的保護下，

若是有人劫持了請求，並對請求中的參數進行了修改，簽名就沒法經過；

若是有人使用已經劫持的URL進行DOS攻擊，服務器則會由於緩存服務器中已經存在簽名或時間戳超時而拒絕服務，因此DOS攻擊也是不可能的；

若是簽名算法和用戶名密碼都暴露了，那齊天大聖來了估計也很差使吧。。。。

最後說一句，全部的安全措施都用上的話有時候不免太過複雜，在實際項目中須要根據自身狀況做出裁剪，好比能夠只使用簽名機制就能夠保證信息不會被篡改，或者定向提供服務的時候只用Token機制就能夠了。如何裁剪，全看項目實際狀況和對接口安全性的要求~