API介面設計:防引數篡改+防二次請求(防重放)
API介面設計:防引數篡改+防二次請求(防重放)
API介面由於需要供第三方服務呼叫,所以必須暴露到外網,並提供了具體請求地址和請求引數
為了防止被第別有用心之人獲取到真實請求引數後再次發起請求獲取資訊,需要採取很多安全機制
1.首先: 需要採用https方式對第三方提供介面,資料的加密傳輸會更安全,即便是被破解,也需要耗費更多時間
2.其次:需要有安全的後臺驗證機制【本文重點】,達到防引數篡改+防二次請求
主要防禦措施可以歸納為兩點:
- 對請求的合法性進行校驗
- 對請求的資料進行校驗
防止重放攻擊必須要保證請求僅一次有效
需要通過在請求體中攜帶當前請求的唯一標識,並且進行簽名防止被篡改。
所以防止重放攻擊需要建立在防止簽名被串改的基礎之上。
請求引數防篡改
採用https協議可以將傳輸的明文進行加密,但是黑客仍然可以截獲傳輸的資料包,進一步偽造請求進行重放攻擊。如果黑客使用特殊手段讓請求方裝置使用了偽造的證書進行通訊,那麼https加密的內容也將會被解密。
在API介面中我們除了使用https協議進行通訊外,還需要有自己的一套加解密機制,對請求引數進行保護,防止被篡改。
過程如下:
- 客戶端使用約定好的祕鑰對傳輸引數進行加密,得到簽名值signature,並且將簽名值也放入請求引數中,傳送請求給服務端
- 服務端接收客戶端的請求,然後使用約定好的祕鑰對請求的引數(除了signature以外)再次進行簽名,得到簽名值autograph。
- 服務端對比signature和autograph的值,如果對比一致,認定為合法請求。如果對比不一致,說明引數被篡改,認定為非法請求。
因為黑客不知道簽名的祕鑰,所以即使擷取到請求資料,對請求引數進行篡改,但是卻無法對引數進行簽名,無法得到修改後引數的簽名值signature。
簽名的祕鑰我們可以使用很多方案,可以採用對稱加密或者非對稱加密。
( 古月: 關於怎麼簽名可以參考阿里的文件
請求籤名說明文件_使用者指南(呼叫 API)_API 閘道器-阿里雲
https://help.aliyun.com/document_detail/29475.html?spm=a2c4g.11186623.2.3.nRdYli
介面鑑權 - 標籤 - 文件平臺 - 騰訊雲
https://cloud.tencent.com/document/product/651/18355 )
防止重放攻擊
基於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引數的“集合”即可。
最終實現程式碼(閘道器層驗證):
1 public class APIAuth extends ZuulFilter {
2 @Override
3 public String filterType() {
4 return "pre";
5 }
6
7 @Override
8 public int filterOrder() {
9 return 0;
10 }
11
12 @Override
13 public boolean shouldFilter() {
14 return true;
15 }
16
17 @Override
18 public Object run() {
19 RequestContext ctx = RequestContext.getCurrentContext();
20 HttpServletRequest request = ctx.getRequest();
21
22 String token = request.getHeader("token");
23 String timestamp = request.getHeader("timestamp");
24 String nonce = request.getHeader("nonce");
25 String sign = request.getHeader("sign");
26
27 //時間限制配置
28 int timeLimit = 60;
29
30 ctx.setSendZuulResponse(false);
31
32 //請求頭引數非空驗證
33 if (StringUtils.isEmpty(token) || StringUtils.isEmpty(timestamp) || StringUtils.isEmpty(nonce) || StringUtils.isEmpty(sign)) {
34 ctx.setResponseBody(JSON.toJSONString(new Result("-1", "請求頭引數不正確")));
35 return null;
36 }
37
38 //請求時間和現在時間對比驗證,發起請求時間和伺服器時間不能超過timeLimit秒
39 if (StringUtils.timeDiffSeconds(new Date(), timestamp) > timeLimit) {
40 ctx.setResponseBody(JSON.toJSONString(new Result("-1", "請求發起時間超過伺服器限制")));
41 return null;
42 }
43
44 //驗證使用者資訊
45 UserInfo userInfo = UserInfoUtil.getInfoByToken(token);
46 if (userInfo == null) {
47 ctx.setResponseBody(JSON.toJSONString(new Result("-1", "錯誤的token資訊")));
48 return null;
49 }
50
51 //驗證相同noce的請求是否已經存在,存在表示為重複請求
52 if (NoceUtil.exsit(userInfo, nonce)) {
53 ctx.setResponseBody(JSON.toJSONString(new Result("-1", "重複的請求")));
54 return null;
55 } else {
56 //如果noce沒有在快取中,則需要加入,並設定過期時間為timeLimit秒
57 NoceUtil.addNoce(userInfo, nonce, timeLimit);
58 }
59
60 //伺服器生成簽名與header中籤名對比
61 String serverSign = SignUtil.getSign(userinfo, token, timestamp, nonce, request);
62 if (!serverSign.equals(sign)) {
63 ctx.setResponseBody(JSON.toJSONString(new Result("-1", "錯誤的簽名信息")));
64 return null;
65 }
66
67 ctx.setSendZuulResponse(true);
68 return null;
69 }
70 }