API接口由於需要供第三方服務調用,所以必須暴露到外網,並提供了具體請求地址和請求參數
爲了防止被第別有用心之人獲取到真實請求參數後再次發起請求獲取信息,需要採取很多安全機制
1.首先: 需要採用https方式對第三方提供接口,數據的加密傳輸會更安全,即便是被破解,也需要耗費更多時間
2.其次:需要有安全的後臺驗證機制【本文重點】,達到防參數篡改+防二次請求
主要防禦措施可以歸納爲兩點:
- 對請求的合法性進行校驗
- 對請求的數據進行校驗
防止重放攻擊必須要保證請求僅一次有效
需要通過在請求體中攜帶當前請求的唯一標識,並且進行簽名防止被篡改。
所以防止重放攻擊需要建立在防止簽名被串改的基礎之上。
請求參數防篡改
採用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參數的“集合”即可。
最終實現代碼(網關層驗證):
public class APIAuth extends ZuulFilter {
@Override
public String filterType() {
return "pre";
}
@Override
public int filterOrder() {
return 0;
}
@Override
public boolean shouldFilter() {
return true;
}
@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
String token = request.getHeader("token");
String timestamp = request.getHeader("timestamp");
String nonce = request.getHeader("nonce");
String sign = request.getHeader("sign");
//時間限制配置
int timeLimit = 60;
ctx.setSendZuulResponse(false);
//請求頭參數非空驗證
if (StringUtils.isEmpty(token) || StringUtils.isEmpty(timestamp) || StringUtils.isEmpty(nonce) || StringUtils.isEmpty(sign)) {
ctx.setResponseBody(JSON.toJSONString(new Result("-1", "請求頭參數不正確")));
return null;
}
//請求時間和現在時間對比驗證,發起請求時間和服務器時間不能超過timeLimit秒
if (StringUtils.timeDiffSeconds(new Date(), timestamp) > timeLimit) {
ctx.setResponseBody(JSON.toJSONString(new Result("-1", "請求發起時間超過服務器限制")));
return null;
}
//驗證用戶信息
UserInfo userInfo = UserInfoUtil.getInfoByToken(token);
if (userInfo == null) {
ctx.setResponseBody(JSON.toJSONString(new Result("-1", "錯誤的token信息")));
return null;
}
//驗證相同noce的請求是否已經存在,存在表示爲重複請求
if (NoceUtil.exsit(userInfo, nonce)) {
ctx.setResponseBody(JSON.toJSONString(new Result("-1", "重複的請求")));
return null;
} else {
//如果noce沒有在緩存中,則需要加入,並設置過期時間爲timeLimit秒
NoceUtil.addNoce(userInfo, nonce, timeLimit);
}
//服務器生成簽名與header中籤名對比
String serverSign = SignUtil.getSign(userinfo, token, timestamp, nonce, request);
if (!serverSign.equals(sign)) {
ctx.setResponseBody(JSON.toJSONString(new Result("-1", "錯誤的簽名信息")));
return null;
}
ctx.setSendZuulResponse(true);
return null;
}
}