如何保證API接口的安全性

 

 

怎樣防偽裝攻擊

防偽裝攻擊：即防止接口被其他人調用，此階段可以理解為比如已經登錄了，然后在請求其他接口的時候，通過Token授權機制來判斷當前請求是否有效

Token是客戶端訪問服務端的憑證。

Token授權機制

• 用戶用密碼登錄或者驗證碼登錄成功后，服務器返回token（通常UUID）給客戶端，並將Token-UserId以鍵值對的形式存放在緩存服務器中。
• 客戶端將token保存在本地，發起后續的相關請求時，將token發回給服務器；
• 服務器檢查token的有效性，有效則返回數據，若無效，分兩種情況：

1. token錯誤，這時需要用戶重新登錄，獲取正確的token
2. token過期，這時客戶端需要再發起一次認證請求，獲取新的token（具體的看服務端和客戶端怎么約定處理）

安全隱患

💣💣💣Token被劫持：被劫持之后，可以偽造請求（重放攻擊）和篡改參數（篡改攻擊）

怎樣防重放攻擊

重放攻擊：所謂重放攻擊就是攻擊者發送一個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程。比如黑客通過抓包獲取到了請求的HTTP報文，然后黑客自己編寫了一個類似的HTTP請求，發送給服務器

timestamp、nonce主要針對每個API保持唯一性

基於時間戳（timestamp）的方案

每次HTTP請求，都需要加上timestamp參數，然后把timestamp和其他參數一起進行數字簽名。因為一次正常的HTTP請求，從發出到達服務器一般都不會超過60s，所以服務器收到HTTP請求之后，首先判斷時間戳參數與當前時間相比較，是否超過了60s，如果超過了則認為是非法的請求。

 

http://baidu.com/index/Info?uid=ZX07&stime=14232323&sign=128728364892304dhfj92932 如果黑客修改stime參數為當前的時間戳，則sign參數對應的數字簽名就會失效，因為黑客不知道token值，沒有辦法生成新的數字簽名

 🌑存在的問題： 黑通過抓包發送請到服務端求一般都會超過60S了，但是如果是在60s之內進行重放攻擊，那就沒辦法了，所以這種方式不能保證接口被多次調用。

基於nonce的方案

nonce(Number once)的意思是僅一次有效的隨機字符串，要求每次請求時，該參數要保證不同，所以該參數一般與時間戳有關,服務端會把每一次請求的nonce保存到數據
工作流程：每次處理HTTP請求時，首先判斷該請求的nonce參數是否在服務端數據庫中，如果存在則認為是非法請求

 讓我們看一個實際的列子：

http://baidu.com/index/Info?uid=ZX07&nonce=53sdkjskd&sign=128728364892304dhfj92932 nonce參數在首次請求時，已經被存儲到了服務器上的“集合”中，再次發送請求會被識別並拒絕。 nonce參數作為數字簽名的一部分，是無法篡改的，因為黑客不清楚token，所以不能生成新的sign。

🌑存在的問題： 那就是對服務器來說永久存儲所有接收到的nonce的代價是非常大的

[最佳方案]基於timestamp和nonce的方案

nonce的一次性可以解決timestamp參數時間限制的問題，timestamp可以解決nonce參數在數據庫“集合”越來越大的問題。在timestamp方案的基礎上，加上nonce參數，因為timstamp參數對於超過60s的請求，都認為非法請求，所以我們只需要存儲60s的nonce參數的“集合”即可

 讓我們看一個實際的列子：

http://baidu.com/index/Info?uid=ZX07&stime=34334232323&nonce=53sdkjskd&sign=128728364892304dhfj92932 # 如果在60s內，重放該HTTP請求，因為nonce參數已經在首次請求的時候被記錄在服務器的nonce參數“集合”中，所以會被判斷為非法請求。 超過60s之后，stime參數就會失效，此時因為黑客不清楚token的值，所以無法重新生成簽名

 

如何正確生成timestamp

問題：由於服務器的時間和客戶端的時間是存在時間差的，所以客戶端時間必須和服務端時間做校驗

先請求服務器上的時間 ServerTime，然后記錄下來，同時記錄當前的時間 LocalTime1,當下次請求接口的時候，最新的時間即是：LocalTime2 - LocalTime1 + ServerTime

• App啟動后通過接口獲取服務器時間 ServerTime，保存本地。並同時記錄當前時間 LocalTime1
• 獲取當前時間：LocalTime2（當前本地時間） - LocalTime1 + ServerTime

怎樣防篡改攻擊

簽名機制

算法：signature（簽名） = MD5算法（token+timestamp+nonce+業務參數）

將“API接口中的token、timestamp、nonce、業務參數"進行MD5算法加密，加密后的數據就是本次請求的簽名signature，服務端接收到請求后以同樣的算法得到簽名，並跟當前的簽名進行比對，如果不一樣，說明參數被更改過，直接返回錯誤標識。

具體流程：

• 請求參數包括token、timestamp、nonce、業務參數、客戶端signature（簽名）
• 將token、timestamp、nonce、業務參數以字母升序（A-Z）排序，按'key1=value1'+ '&' + 'key2=value2'連接所有參數得到字符串signStr
• 將字符串signStr進行MD5運行得到新的簽名newSignature
• newSignature和客戶端發送的signature做比較

OAuth2.0

 

 如果接口屬於開放的API，則適合使用OAuth2.0的認證機制來處理。

 

• 用來代替密碼，供第三方應用使用，需要用戶授權
• 應用通過憑證（Access Token）向資源服務器請求相關資源

HTTPS

HTTPS：HTTPS在HTTP的基礎上添加了TSL/SSL安全協議，不過，HTTPS也不是絕對安全的，也存在被劫持的可能，但相對HTTP毋庸置疑是更加安全的

🌑缺點： 服務器對HTTPS的配置相對有點復雜，還需要到CA申請證書，而且一般還是收費的。而且，HTTPS效率也比較低。一般，只有安全要求比較高的系統才會采用HTTPS，比如銀行。而大部分對安全要求沒那么高的App還是采用HTTP的方式

IP白名單

僅允許IP白名單內的IP訪問，其余的IP均不允許訪問，可用於鑒權，防止代理ip被亂用，個人目前還未曾過多涉及，所以不做更多闡述。

總結

只有在token有效、timestamp未超時、緩存服務器中不存在nonce三種情況同時滿足，接口請求才有效。服務端可以寫一個過濾器對token、timestamp和nonce進行過濾和驗證