前言 我們的API接口都是提供給第三方服務/客戶端調用，所有請求地址以及請求參數(shù)都是暴露給用戶的。 我們每次請求一個HTTP請求，用戶都可以通過F12,或者抓包工具fd看到請求的URL鏈接，然后copy出來。這樣是非常不安全的，有人可能會惡意的刷我們的接口，那這時該怎么辦呢？防重放攻擊就出來了。 什
我們的API接口是為第三方服務/客戶端調用而設計的。所有請求地址和參數(shù)都是對用戶公開的。然而，每次發(fā)起HTTP請求時，用戶都可以通過F12或抓包工具fd查看請求的URL鏈接，甚至將其復制出來。這種情況非常不安全，因為有人可能會惡意刷我們的接口。這時，防重放攻擊就顯得尤為重要。
防重放攻擊是指通過惡意重復發(fā)送已經獲取的有效數(shù)據(jù)包來攻擊系統(tǒng)。以掘金文章點贊為例，當用戶點贊后，H5會向掘金后端服務器發(fā)送請求。用戶可以通過F12查看完整的請求參數(shù)，包括URL和參數(shù)等，然后將其復制出來，實施重放攻擊。
具體來說，服務端返回的是重復點贊，也就是掘金并沒有采取防重放攻擊的措施。掘金通過查詢數(shù)據(jù)庫（推測item_id是唯一索引值）來判斷是否已經點贊，然后返回前端邏輯。
那么，我們理解的放重放攻擊是指什么呢？
簡單來說，就是前端和客戶端約定一個算法（比如md5），通過加密時間戳+傳入字段來防止重復請求。然后，這個時間戳可以設定為30秒或60秒過期。如果30秒內有人不斷刷我們的接口，我們還可以新增一個字段為nonceKey，30秒內隨機不重復。這個字段存放在Redis，并且30秒過期。如果下一次請求nonceKey還在Redis中，我們就認為是重復請求，可以拒絕。
通過這樣簡單的算法，就可以實現(xiàn)防重放攻擊。
防重放攻擊的算法實現(xiàn)如下：
首先定義一個全局攔截器：
@Component
public class TokenInterceptor implements HandlerInterceptor {
@Autowired
private StringRedisTemplate redisService;
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
throws Exception {
// 省略部分代碼
}
}
定義具體的算法實現(xiàn)：
public class SecretUtils {
// 省略部分代碼
}
前端會通過預先約定好的算法和方式，將字符串從小到大進行排序 + timestamp，然后md5進行加密生成token傳給后端。后端根據(jù)算法+方式來校驗token是否有效。如果其中有人修改了參數(shù)，那么token就會校驗失敗，直接拒絕即可。如果沒修改參數(shù)，timestamp如果大于60秒，則認為是防重放攻擊，直接拒絕；如果小于30秒，則將nonceKey加入到Redis里面。這里nonceKey用的是timestamp字段，如果不存在則第一次請求，如果存在，則直接拒絕即可。
防重放攻擊的Q&A：
Q：客戶端和服務端生成的時間戳不一致怎么辦
A：客戶端和服務端生成的是時間戳，不是具體的時間。時間戳是指格林威治時間1970年01月01日00時00分00秒（北京時間1970年01月01日08時00分00秒）起至現(xiàn)在的總秒數(shù)。
Q：HTTPS數(shù)據(jù)加密是否可以防止重放攻擊
A：不可以。HTTPS是在傳輸過程中保證了加密，也就是說如果中間人獲取到了請求，他是無法解開傳輸?shù)膬热莸摹?
舉個最簡單的例子，上課和同學傳紙條的時候，為了不讓中間給遞紙條的人看到或者修改，可以在紙條上寫成只有雙方能看明白密文，這樣遞紙條的過程就安全了，傳紙條過程中的人就看不懂你的內容了。但是如果給你寫紙條的人要搞事情，那就是加密解決不了的了。這時候就需要防重放來解決了。
Q：防重放攻擊是否有用，屬于脫褲子放屁
A：個人感覺有一點點吧。比如防重放攻擊的算法+加密方式其實大多數(shù)用的都是這些，其實攻擊人很容易就能猜到token生成的方式，比如timestamp + 從小到大排序。因此我們加入了salt來混淆視聽，這個salt需要前端、客戶端安全的存儲，不能讓用戶知道，比如js混淆等等。但其實通過抓包，js分析還是很容易能拿到的。但無形中增加了攻擊人的成本，比如網(wǎng)易云登錄的js加密類似。
Q：做了防重放，支付，點贊等是否不需要做冪等了
A：需要。最重要的冪等，一定要用數(shù)據(jù)庫來實現(xiàn)，比如唯一索引。其他都不可相信。
以我個人的理解，防重放用處不大。其他安全措施，比如非對稱的RSA驗簽更加有效。就算用戶拿到了請求的所有信息，你的接口也一定要做冪等的，尤其是像支付轉賬等高危操作，冪等才是最有用的防線。而且防重發(fā)生成token的算法，大家都這樣搞，攻擊者怎么可能不知道呢？這點我不太理解。
現(xiàn)在面試也比較考驗面試官的水平，下篇我會講下最近的一些面試體驗和感受，歡迎大家點贊收藏。
小編推薦閱讀
本站所有軟件，都由網(wǎng)友上傳，如有侵犯你的版權，請發(fā)郵件[email protected]
湘ICP備2022002427號-10 湘公網(wǎng)安備：43070202000427號© 2013~2025 haote.com 好特網(wǎng)
