後端交互校驗

交互校驗經常使用參數：
(1) Authorization/session_id

        用戶認證參數。
(2) 客戶端簽名 Signture

        簽名的功能是校驗服務端收到的請求來自於對應的客戶端，確保對不是對應客戶端發起的請求不予響應。其中常見的簽名方法有ASE加密解密，比對信息摘要等。最簡單的方式好比將一個隨機值+時間戳+約定值進行組合順序的MD5加密，而後在服務器收到該請求時生成新的簽名進行比對，若簽名一致則響應該請求，不然不予響應。其中signture能夠這樣生成：

        signture = md5（隨機值 + 時間戳timestamp + 約定值）

 

常見問題舉例：

(1) 重放攻擊

    典型的重放攻擊是經過抓包客戶端生成的簽名不斷地進行接口請求。如利用該簽名不停地請求短信驗證碼接口，直到服務器的驗證碼餘額耗光。

    防止重放攻擊的最有效方式就是保持signture的惟一性。客戶端必須生成惟一的signture，同時服務端也要保證對一個signture只響應一次請求。

    要確保signture的惟一性，能夠在生成簽名時採用時間戳timestamp這個參數的惟一性；同時爲了確保服務端響應的惟一性，能夠標記記錄響應過的signture，再重複接收時不予響應。

    而在服務器端對signture作記錄，通常能夠採用 磁盤文件、數據庫、緩存（Redis,Memcached等）記錄。其中寫進磁盤文件存在調用效率低，分佈式系統不適用等弊端。若數據量較小時可採用緩存存儲，若數據量較大可採起數據庫存取（注意：需考慮請求數增長會加大數據庫壓力的問題）。

(2)  簽名超時機制

    上述確保簽名惟一性的方法，在記錄的signture數量增長到必定數量後會效率很低。每次請求都須要去比對以前請求記錄下的簽名，明顯是很不合理的。因此對於簽名的記錄，應當有必定的時效性，好比作一個數據庫臨時表，或者是redis緩存。在考慮時效性的同時，咱們還須要考慮到記錄的簽名到期後，會被攻擊者繼續利用失效簽名進行重放攻擊的風險。

    因此須要引入簽名超時機制，當請求中的timestamp參數與當前服務端時間相隔大於signture的緩存時間，則不去響應該請求。通常超時時間須要知足：

    （服務端當前時間 - 客戶端提交時間） < 超時時間 < signture緩存時間

(3)  超時機制下溢攻擊

    按照上面超時機制的原理，對應的程序邏輯應該以下：

    if( (服務端時間 - 客戶端時間) < 超時時間 ){

        //正確響應

    }else{

        //超時，不予響應

    }

    可是其中也須要考慮客戶端提交時間遠大於服務器時間的狀況，及攻擊者在signture失效後，採用超前的timestamp參數生成signture，進行重放攻擊。其原理是服務端時間 - 客戶端提交時間 = 負數 < 超時時間，從而繞過了超時機制，因此在計算服務端時間與客戶端時間間隔時，須要額外判斷其間隔爲整數。

    固然，爲了確保服務端與客戶端時間的一致性，常常須要服務端提供查詢時間接口，使得客戶端提交的時間戳參數與服務端的時間一致。

 

以上是我在作後端交互時的一些總結，後續若遇到其餘問題，會繼續更新。

若其中有總結錯誤的地方，也請你們多多指教。