HTTPS數(shù)據(jù)加密是否可以防止重放攻擊？

否，加密可以有效防止明文數(shù)據(jù)被監(jiān)聽，但是卻防止不了重放攻擊。

防重放機(jī)制

我們在設(shè)計(jì)接口的時(shí)候，最怕一個(gè)接口被用戶截取用于重放攻擊。重放攻擊是什么呢？就是把你的請求原封不動地再發(fā)送一次，兩次...n次，一般正常的請求都會通過驗(yàn)證進(jìn)入到正常邏輯中，如果這個(gè)正常邏輯是插入數(shù)據(jù)庫操作，那么一旦插入數(shù)據(jù)庫的語句寫的不好，就有可能出現(xiàn)多條重復(fù)的數(shù)據(jù)。一旦是比較慢的查詢操作，就可能導(dǎo)致數(shù)據(jù)庫堵住等情況。
付款接口，或者購買接口會造成損失
需要采用防重放的機(jī)制來做請求驗(yàn)證。

timestamp+nonce

我們常用的防止重放的機(jī)制是使用timestamp和nonce來做的重放機(jī)制。
timestamp用來表示請求的當(dāng)前時(shí)間戳，這個(gè)時(shí)間戳當(dāng)然要和服務(wù)器時(shí)間戳進(jìn)行校正過的。我們預(yù)期正常請求帶的timestamp參數(shù)會是不同的（預(yù)期是正常的人每秒至多只會做一個(gè)操作）。每個(gè)請求帶的時(shí)間戳不能和當(dāng)前時(shí)間超過一定規(guī)定的時(shí)間。比如60s。這樣，這個(gè)請求即使被截取了，你也只能在60s內(nèi)進(jìn)行重放攻擊。過期失效。
但是這樣也是不夠的，還有給攻擊者60s的時(shí)間。所以我們就需要使用一個(gè)nonce，隨機(jī)數(shù)。
nonce是由客戶端根據(jù)足夠隨機(jī)的情況生成的，比如 md5(timestamp+rand(0, 1000)); 也可以使用UUID, 它就有一個(gè)要求，正常情況下，在短時(shí)間內(nèi)（比如60s）連續(xù)生成兩個(gè)相同nonce的情況幾乎為0。

服務(wù)端

服務(wù)端第一次在接收到這個(gè)nonce的時(shí)候做下面行為：?1 去redis中查找是否有key為nonce:{nonce}的string?2 如果沒有，則創(chuàng)建這個(gè)key，把這個(gè)key失效的時(shí)間和驗(yàn)證timestamp失效的時(shí)間一致，比如是60s。?3 如果有，說明這個(gè)key在60s內(nèi)已經(jīng)被使用了，那么這個(gè)請求就可以判斷為重放請求。
示例
那么比如，下面這個(gè)請求：
http://a.com?uid=123&timestam...
這個(gè)請求中的uid是我們真正需要傳遞的有意義的參數(shù)
timestamp，nonce，sign都是為了簽名和防重放使用。
timestamp是發(fā)送接口的時(shí)間，nonce是隨機(jī)串，sign是對uid，timestamp,nonce(對于一些rest風(fēng)格的api，我建議也把url放入sign簽名)。簽名的方法可以是md5({秘要}key1=val1&key2=val2&key3=val3...)
服務(wù)端接到這個(gè)請求：?1 先驗(yàn)證sign簽名是否合理，證明請求參數(shù)沒有被中途篡改?2 再驗(yàn)證timestamp是否過期，證明請求是在最近60s被發(fā)出的?3 最后驗(yàn)證nonce是否已經(jīng)有了，證明這個(gè)請求不是60s內(nèi)的重放請求

web層面也可以采用在頁面中加入token方式，手機(jī)驗(yàn)證碼，滑動驗(yàn)證碼等方式來防止攻擊

總結(jié)

以上是生活随笔為你收集整理的API设计中防重放攻击的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。