API設計中防重放攻擊

否，加密可以有效防止明文資料被監聽，但是卻防止不了重放攻擊。

我們在設計介面的時候，最怕乙個介面被使用者擷取用於重放攻擊。重放攻擊是什麼呢？就是把你的請求原封不動地再傳送一次，兩次...n次，一般正常的請求都會通過驗證進入到正常邏輯中，如果這個正常邏輯是插入資料庫操作，那麼一旦插入資料庫的語句寫的不好，就有可能出現多條重複的資料。一旦是比較慢的查詢操作，就可能導致資料庫堵住等情況。

付款介面，或者購買介面會造成損失

需要採用防重放的機制來做請求驗證。

我們常用的防止重放的機制是使用timestamp和nonce來做的重放機制。

timestamp用來表示請求的當前時間戳，這個時間戳當然要和伺服器時間戳進行校正過的。我們預期正常請求帶的timestamp引數會是不同的（預期是正常的人每秒至多只會做乙個操作）。每個請求帶的時間戳不能和當前時間超過一定規定的時間。比如60s。這樣，這個請求即使被擷取了，你也只能在60s內進行重放攻擊。過期失效。

但是這樣也是不夠的，還有給攻擊者60s的時間。所以我們就需要使用乙個nonce，隨機數。

nonce是由客戶端根據足夠隨機的情況生成的，比如 md5(timestamp+rand(0, 1000)); 也可以使用uuid, 它就有乙個要求，正常情況下，在短時間內（比如60s）連續生成兩個相同nonce的情況幾乎為0。

服務端第一次在接收到這個nonce的時候做下面行為：
1 去redis中查詢是否有key為nonce:的string
2 如果沒有，則建立這個key，把這個key失效的時間和驗證timestamp失效的時間一致，比如是60s。
3 如果有，說明這個key在60s內已經被使用了，那麼這個請求就可以判斷為重放請求。

示例那麼比如，下面這個請求：

這個請求中的uid是我們真正需要傳遞的有意義的引數

timestamp，nonce，sign都是為了簽名和防重放使用。

timestamp是傳送介面的時間，nonce是隨機串，sign是對uid，timestamp,nonce(對於一些rest風格的api，我建議也把url放入sign簽名)。簽名的方法可以是md5(key1=val1&key2=val2&key3=val3...)

服務端接到這個請求：
1 先驗證sign簽名是否合理，證明請求引數沒有被中途篡改
2 再驗證timestamp是否過期，證明請求是在最近60s被發出的
3 最後驗證nonce是否已經有了，證明這個請求不是60s內的重放請求

web層面也可以採用在頁面中加入token方式，手機驗證碼，滑動驗證碼等方式來防止攻擊

API設計中防重放攻擊

https資料加密是否可以防止重放攻擊？否，加密可以有效防止明文資料被監聽，但是卻防止不了重放攻擊。我們在設計介面的時候，最怕乙個介面被使用者擷取用於重放攻擊。重放攻擊是什麼呢？就是把你的請求原封不動地再傳送一次，兩次.n次，一般正常的請求都會通過驗證進入到正常邏輯中，如果這個正常邏輯是插入資料庫操...

防重放攻擊

以前總是通過timestamp來防止重放攻擊，但是這樣並不能保證每次請求都是一次性的。今天看到了一篇文章介紹的通過nonce number used once 來保證一次有效，感覺兩者結合一下，就能達到乙個非常好的效果了。重放攻擊是計算機世界黑客常用的攻擊方式之一，所謂重放攻擊就是攻擊者傳送乙個目的...

web api的設計 防重放攻擊

重放攻擊 replay attacks 指攻擊者傳送乙個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程，破壞認證的正確性。重放攻擊。防重放攻擊中，最重要的手段是給訊息打上乙個唯 一 不可以重新生成的編號，保證這個編號只能使用一次。一 利用timestamp。在引數中加入timest...