API接口防止參數篡改和重放攻擊

時間 2020-03-10

原文原文鏈接

API重放攻擊（Replay Attacks）又稱重播攻擊、回放攻擊。他的原理就是把以前竊聽到的數據原封不動的從新發送給接收方。HTTPS並不能防止這種攻擊，雖然傳輸的數據是通過加密的，竊聽者沒法獲得數據的準肯定義，可是能夠從請求的接收方地址分析出這些數據的做用。好比用戶登陸請求時攻擊者雖然沒法竊聽密碼，可是卻能夠截取加密後的口令而後將其重放，從而利用這種方式進行有效的攻擊。redis

所謂重放攻擊就是攻擊者發送一個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程，重放攻擊是計算機世界黑客經常使用的攻擊方式之一。sql

一次HTTP請求，從請求方到接收方中間要通過不少個路由器和交換機，攻擊者能夠在中途截獲請求的數據。假設在一個網上存款系統中，一條消息表示用戶支取了一筆存款，攻擊者徹底能夠屢次發送這條消息而偷竊存款。數據庫

重放是二次請求，若是API接口沒有作對應的安全防禦，將可能形成很嚴重的後果。json

API接口常見的安全防禦要作的主要有以下幾點：

防止sql注入
防止xss攻擊
防止請求參數被串改
防止重放攻擊

主要防護措施能夠概括爲兩點：跨域

對請求的合法性進行校驗
對請求的數據進行校驗

防止重放攻擊必需要保證請求僅一次有效
須要經過在請求體中攜帶當前請求的惟一標識，而且進行簽名防止被篡改。
因此防止重放攻擊須要創建在防止簽名被串改的基礎之上。緩存

請求參數防篡改

採用https協議能夠將傳輸的明文進行加密，可是黑客仍然能夠截獲傳輸的數據包，進一步僞造請求進行重放攻擊。若是黑客使用特殊手段讓請求方設備使用了僞造的證書進行通訊，那麼https加密的內容也將會被解密。
在API接口中咱們除了使用https協議進行通訊外，還須要有本身的一套加解密機制，對請求參數進行保護，防止被篡改。
過程以下：安全

客戶端使用約定好的祕鑰對傳輸參數進行加密，獲得簽名值signature，而且將簽名值也放入請求參數中，發送請求給服務端

服務端接收客戶端的請求，而後使用約定好的祕鑰對請求的參數（除了signature之外）再次進行簽名，獲得簽名值autograph。

服務端對比signature和autograph的值，若是對比一致，認定爲合法請求。若是對比不一致，說明參數被篡改，認定爲非法請求。

由於黑客不知道簽名的祕鑰，因此即便截取到請求數據，對請求參數進行篡改，可是卻沒法對參數進行簽名，沒法獲得修改後參數的簽名值signature。
簽名的祕鑰咱們可使用不少方案，能夠採用對稱加密或者非對稱加密。服務器

防止重放攻擊

基於timestamp的方案

每次HTTP請求，都須要加上timestamp參數，而後把timestamp和其餘參數一塊兒進行數字簽名。由於一次正常的HTTP請求，從發出到達服務器通常都不會超過60s，因此服務器收到HTTP請求以後，首先判斷時間戳參數與當前時間相比較，是否超過了60s，若是超過了則認爲是非法的請求。xss

通常狀況下，黑客從抓包重放請求耗時遠遠超過了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接口驗證流程：

API重放攻擊（Replay Attacks）又稱重播攻擊、回放攻擊。他的原理就是把以前竊聽到的數據原封不動的從新發送給接收方。HTTPS並不能防止這種攻擊，雖然傳輸的數據是通過加密的，竊聽者沒法獲得數據的準肯定義，可是能夠從請求的接收方地址分析出這些數據的做用。好比用戶登陸請求時攻擊者雖然沒法竊聽密碼，可是卻能夠截取加密後的口令而後將其重放，從而利用這種方式進行有效的攻擊。

所謂重放攻擊就是攻擊者發送一個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程，重放攻擊是計算機世界黑客經常使用的攻擊方式之一。

一次HTTP請求，從請求方到接收方中間要通過不少個路由器和交換機，攻擊者能夠在中途截獲請求的數據。假設在一個網上存款系統中，一條消息表示用戶支取了一筆存款，攻擊者徹底能夠屢次發送這條消息而偷竊存款。

重放是二次請求，若是API接口沒有作對應的安全防禦，將可能形成很嚴重的後果。

API接口常見的安全防禦要作的主要有以下幾點：

防止sql注入
防止xss攻擊
防止請求參數被串改
防止重放攻擊

主要防護措施能夠概括爲兩點：

對請求的合法性進行校驗
對請求的數據進行校驗

防止重放攻擊必需要保證請求僅一次有效
須要經過在請求體中攜帶當前請求的惟一標識，而且進行簽名防止被篡改。
因此防止重放攻擊須要創建在防止簽名被串改的基礎之上。

請求參數防篡改

客戶端使用約定好的祕鑰對傳輸參數進行加密，獲得簽名值signature，而且將簽名值也放入請求參數中，發送請求給服務端

服務端接收客戶端的請求，而後使用約定好的祕鑰對請求的參數（除了signature之外）再次進行簽名，獲得簽名值autograph。

服務端對比signature和autograph的值，若是對比一致，認定爲合法請求。若是對比不一致，說明參數被篡改，認定爲非法請求。

由於黑客不知道簽名的祕鑰，因此即便截取到請求數據，對請求參數進行篡改，可是卻沒法對參數進行簽名，沒法獲得修改後參數的簽名值signature。
簽名的祕鑰咱們可使用不少方案，能夠採用對稱加密或者非對稱加密。

防止重放攻擊

基於timestamp的方案

每次HTTP請求，都須要加上timestamp參數，而後把timestamp和其餘參數一塊兒進行數字簽名。由於一次正常的HTTP請求，從發出到達服務器通常都不會超過60s，因此服務器收到HTTP請求以後，首先判斷時間戳參數與當前時間相比較，是否超過了60s，若是超過了則認爲是非法的請求。

通常狀況下，黑客從抓包重放請求耗時遠遠超過了60s，因此此時請求中的timestamp參數已經失效了。
若是黑客修改timestamp參數爲當前的時間戳，則signature參數對應的數字簽名就會失效，由於黑客不知道簽名祕鑰，沒有辦法生成新的數字簽名。

但這種方式的漏洞也是顯而易見的，若是在60s以後進行重放攻擊，那就沒辦法了，因此這種方式不能保證請求僅一次有效。

基於nonce的方案

基於timestamp和nonce的方案

// 獲取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請求重放攻擊。

// 獲取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請求重放攻擊。