{近期領導要求我對公司業務的支付類的ocr接口做研究，是否存在支付接口重放攻擊，so。。。。。}
API重放攻擊（Replay Attacks）又稱重播攻擊、回放攻擊。他的原理就是把之前竊聽到的數據原封不動的重新發送給接收方。HTTPS並不能防止這種攻擊，雖然傳輸的數據是經過加密的，竊聽者無法得到數據的准確定義，但是可以從請求的接收方地址分析出這些數據的作用。比如用戶登錄請求時攻擊者雖然無法竊聽密碼，但是卻可以截取加密后的口令然后將其重放，從而利用這種方式進行有效的攻擊。
所謂重放攻擊就是攻擊者發送一個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程，重放攻擊是計算機世界黑客常用的攻擊方式之一。
一次HTTP請求，從請求方到接收方中間要經過很多個路由器和交換機，攻擊者可以在中途截獲請求的數據。假設在一個網上存款系統中，一條消息表示用戶支取了一筆存款，攻擊者完全可以多次發送這條消息而偷竊存款。
重放是二次請求，如果API接口沒有做對應的安全防護，將可能造成很嚴重的后果。
API接口常見的安全防護要做的主要有如下幾點：
- 防止sql注入
- 防止xss攻擊
- 防止請求參數被串改
- 防止重放攻擊
主要防御措施可以歸納為兩點：
- 對請求的合法性進行校驗
- 對請求的數據進行校驗
防止重放攻擊必須要保證請求僅一次有效
需要通過在請求體中攜帶當前請求的唯一標識，並且進行簽名防止被篡改。
所以防止重放攻擊需要建立在防止簽名被串改的基礎之上。
請求參數防篡改
采用https協議可以將傳輸的明文進行加密，但是黑客仍然可以截獲傳輸的數據包，進一步偽造請求進行重放攻擊。如果黑客使用特殊手段讓請求方設備使用了偽造的證書進行通信，那么https加密的內容也將會被解密。
在API接口中我們除了使用https協議進行通信外，還需要有自己的一套加解密機制，對請求參數進行保護，防止被篡改。
過程如下：
- 客戶端使用約定好的秘鑰對傳輸參數進行加密，得到簽名值signature，並且將簽名值也放入請求參數中，發送請求給服務端
- 服務端接收客戶端的請求，然后使用約定好的秘鑰對請求的參數（除了signature以外）再次進行簽名，得到簽名值autograph。
- 服務端對比signature和autograph的值，如果對比一致，認定為合法請求。如果對比不一致，說明參數被篡改，認定為非法請求。
因為黑客不知道簽名的秘鑰，所以即使截取到請求數據，對請求參數進行篡改，但是卻無法對參數進行簽名，無法得到修改后參數的簽名值signature。
簽名的秘鑰我們可以使用很多方案，可以采用對稱加密或者非對稱加密。
防止重放攻擊
基於timestamp的方案
每次HTTP請求，都需要加上timestamp參數，然后把timestamp和其他參數一起進行數字簽名。因為一次正常的HTTP請求，從發出到達服務器一般都不會超過60s，所以服務器收到HTTP請求之后，首先判斷時間戳參數與當前時間相比較，是否超過了60s，如果超過了則認為是非法的請求。
一般情況下，黑客從抓包重放請求耗時遠遠超過了60s，所以此時請求中的timestamp參數已經失效了。
如果黑客修改timestamp參數為當前的時間戳，則signature參數對應的數字簽名就會失效，因為黑客不知道簽名秘鑰，沒有辦法生成新的數字簽名。
但這種方式的漏洞也是顯而易見的，如果在60s之后進行重放攻擊，那就沒辦法了，所以這種方式不能保證請求僅一次有效。
基於nonce的方案
nonce的意思是僅一次有效的隨機字符串，要求每次請求時，該參數要保證不同，所以該參數一般與時間戳有關，我們這里為了方便起見，直接使用時間戳的16進制，實際使用時可以加上客戶端的ip地址，mac地址等信息做個哈希之后，作為nonce參數。
我們將每次請求的nonce參數存儲到一個“集合”中，可以json格式存儲到數據庫或緩存中。
每次處理HTTP請求時，首先判斷該請求的nonce參數是否在該“集合”中，如果存在則認為是非法請求。
nonce參數在首次請求時，已經被存儲到了服務器上的“集合”中，再次發送請求會被識別並拒絕。
nonce參數作為數字簽名的一部分，是無法篡改的，因為黑客不清楚token，所以不能生成新的sign。
這種方式也有很大的問題，那就是存儲nonce參數的“集合”會越來越大，驗證nonce是否存在“集合”中的耗時會越來越長。我們不能讓nonce“集合”無限大，所以需要定期清理該“集合”，但是一旦該“集合”被清理，我們就無法驗證被清理了的nonce參數了。也就是說，假設該“集合”平均1天清理一次的話，我們抓取到的該url，雖然當時無法進行重放攻擊，但是我們還是可以每隔一天進行一次重放攻擊的。而且存儲24小時內，所有請求的“nonce”參數，也是一筆不小的開銷。
基於timestamp和nonce的方案
nonce的一次性可以解決timestamp參數60s的問題，timestamp可以解決nonce參數“集合”越來越大的問題。
防止重放攻擊一般和防止請求參數被串改一起做，請求的Headers數據如下圖所示。
我們在timestamp方案的基礎上，加上nonce參數，因為timstamp參數對於超過60s的請求，都認為非法請求，所以我們只需要存儲60s的nonce參數的“集合”即可。
API接口驗證流程：
// 獲取token
String token = request.getHeader("token");
// 獲取時間戳
String timestamp = request.getHeader("timestamp");
// 獲取隨機字符串
String nonceStr = request.getHeader("nonceStr");
// 獲取請求地址
String url = request.getHeader("url");
// 獲取簽名
String signature = request.getHeader("signature");
// 判斷參數是否為空
if (StringUtils.isBlank(token) || StringUtils.isBlank(timestamp) || StringUtils.isBlank(nonceStr) || StringUtils.isBlank(url) || StringUtils.isBlank(signature)) {
//非法請求
return;
}
//驗證token有效性，得到用戶信息
UserTokenInfo userTokenInfo = TokenUtils.getUserTokenInfo(token);
if (userTokenInfo == null) {
//token認證失敗（防止token偽造）
return;
}
// 判斷請求的url參數是否正確
if (!request.getRequestURI().equals(url)){
//非法請求 (防止跨域攻擊)
return;
}
// 判斷時間是否大於60秒
if(DateUtils.getSecond()-DateUtils.toSecond(timestamp)>60){
//請求超時(防止重放攻擊)
return;
}
// 判斷該用戶的nonceStr參數是否已經在redis中
if (RedisUtils.haveNonceStr(userTokenInfo,nonceStr)){
//請求僅一次有效（防止短時間內的重放攻擊）
return;
}
// 對請求頭參數進行簽名
String stringB = SignUtil.signature(token, timestamp, nonceStr, url,request);
// 如果簽名驗證不通過
if (!signature.equals(stringB)) {
//非法請求（防止請求參數被篡改）
return;
}
// 將本次用戶請求的nonceStr參數存到redis中設置60秒后自動刪除
RedisUtils.saveNonceStr(userTokenInfo,nonceStr,60);
//開始處理合法的請求
|
基於以上的方案就可以做到防止API接收的參數被篡改和防止API請求重放攻擊。
原文鏈接：https://blog.csdn.net/weixin_39997829/article/details/89083139