在大前端時(shí)代的安全性一文中講了 Web 前端和 Native 客戶端如何從數(shù)據(jù)安全層面做反爬蟲策略，本文接著之前的背景，將從 API 數(shù)據(jù)接口的層面講一種技術(shù)方案，實(shí)現(xiàn)數(shù)據(jù)安全。

成都創(chuàng)新互聯(lián)公司主營大箐山網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶APP軟件開發(fā),大箐山h5小程序制作搭建,大箐山網(wǎng)站營銷推廣歡迎大箐山等地區(qū)企業(yè)咨詢

一、 API 接口請(qǐng)求安全性問題

API 接口存在很多常見的安全性問題，常見的有下面幾種情況

1. 即使采用 HTTPS，諸如 Charles、Wireshark 之類的專業(yè)抓包工具可以扮演證書頒發(fā)、校驗(yàn)的角色，因此可以查看到數(shù)據(jù)
2. 拿到請(qǐng)求信息后原封不動(dòng)的發(fā)起第二個(gè)請(qǐng)求，在服務(wù)器上生產(chǎn)了部分臟數(shù)據(jù)(接口是背后的邏輯是對(duì) DB 的數(shù)據(jù)插入、刪除等)

所以針對(duì)上述的問題也有一些解決方案：

1. HTTPS 證書的雙向認(rèn)證解決抓包工具問題
2. 假如通過網(wǎng)絡(luò)層高手截獲了 HTTPS 加證書認(rèn)證后的數(shù)據(jù)，所以需要對(duì)請(qǐng)求參數(shù)做簽名
3. 「防重放策略」解決請(qǐng)求的多次發(fā)起問題
4. 請(qǐng)求參數(shù)和返回內(nèi)容做額外 RSA 加密處理，即使截獲，也無法查看到明文。

關(guān)于 HTTPS 證書雙向認(rèn)證和 Web 端反爬蟲技術(shù)方案均在大前端時(shí)代的安全性一文中有具體講解。接下來引出本文主角：防重放

二、 請(qǐng)求參數(shù)防篡改

在之前的文章也講過，HTTPS 依舊可以被抓包，造成安全問題。抓包工具下數(shù)據(jù)依舊是裸奔的，可以查看Charles 從入門到精通文中講的如何獲取 HTTPS 數(shù)據(jù)。

假如通過網(wǎng)絡(luò)層高手截獲了 HTTPS 加證書認(rèn)證后的數(shù)據(jù)，所以需要對(duì)請(qǐng)求參數(shù)做簽名。步驟如下

• 客戶端使用約定好的密鑰對(duì)請(qǐng)求參數(shù)進(jìn)行加密，得到簽名 signature。并將簽名加入到請(qǐng)求參數(shù)中，發(fā)送給服務(wù)端
• 服務(wù)端接收到客戶端請(qǐng)求，使用約定好的密鑰對(duì)請(qǐng)求參數(shù)(不包括 signature)進(jìn)行再次簽名，得到值 autograph
• 服務(wù)器對(duì)比 signature 和 autograph，相等則認(rèn)為是一次合法請(qǐng)求，否則則認(rèn)為參數(shù)被篡改，判定為一次非法請(qǐng)求

因?yàn)橹虚g人不知道簽名密鑰，所以即使攔截到請(qǐng)求，修改了某項(xiàng)參數(shù)，但是無法得到正確的簽名 signature，這樣構(gòu)造的一個(gè)請(qǐng)求，會(huì)被服務(wù)器判定為一次非法請(qǐng)求。

三、 防重放策略

在工程師文化中，我們要做一個(gè)事情，就首先要對(duì)這個(gè)事情下個(gè)定義。我們才能知道做什么、怎么做。

理論上，一個(gè) API 接口請(qǐng)求被收到，服務(wù)會(huì)做校驗(yàn)，但是當(dāng)一個(gè)合法請(qǐng)求被中間人攔截后，中間人原封不動(dòng)得重復(fù)發(fā)送該請(qǐng)求一次或多次，這種重復(fù)利用合法請(qǐng)求進(jìn)行得攻擊被成為重放。

重放會(huì)造成服務(wù)器問題，所以我們需要針對(duì)重放做防重放。本質(zhì)上就是如何區(qū)別去一次正常、合法的請(qǐng)求。

3.1 基于 timestamp 的方案

理論上，客戶端發(fā)起一次請(qǐng)求，到服務(wù)端接收到這個(gè)請(qǐng)求的時(shí)間，業(yè)界判定為不超過60秒。利用這個(gè)特征，客戶端每次請(qǐng)求都加上 timestamp1，客戶端將 timestamp1 和其他請(qǐng)求參數(shù)一起簽名得到 signature，之后發(fā)送請(qǐng)求到服務(wù)器。

• 服務(wù)器拿到當(dāng)前時(shí)間戳 timestamp2，timestap2 - timestamp1 > 60s，則認(rèn)為非法
• 服務(wù)端接收到客戶端請(qǐng)求，使用約定好的密鑰對(duì)請(qǐng)求參數(shù)(不包括 signature、timestamp1)進(jìn)行再次簽名，得到值 autograph。比對(duì) signature 和 autograph，若不相等則認(rèn)為是一次非法請(qǐng)求

假如中間人攔截到請(qǐng)求，修改了 timestamp 或者其他的任何參數(shù)，但是不知道密鑰，所以服務(wù)器依舊判定為非法請(qǐng)求。

中間人從抓包、篡改參數(shù)、發(fā)起請(qǐng)求的過程一般來說大于60秒，所以服務(wù)器依舊會(huì)判定為非法請(qǐng)求。

基于 timestamp 的設(shè)計(jì)缺陷也很明顯，種種原因下，60秒內(nèi)的請(qǐng)求，會(huì)鉆規(guī)則漏洞，服務(wù)器判定為一次合法請(qǐng)求。

3.2 基于 nonce 的方案

既然時(shí)間戳?xí)新┒?，那么新方案是基于隨機(jī)字符串 nonce。也就是說每次請(qǐng)求都加入一個(gè)隨機(jī)字符串，然后將其他參數(shù)一起利用密鑰加密得到簽名 signature。服務(wù)端收到請(qǐng)求后

• 先判斷 nonce 參數(shù)是否能存在于某個(gè)集合中，如果存在則認(rèn)為是非法請(qǐng)求;如果不存在，則將 nonce 添加到當(dāng)前的集合中
• 服務(wù)端將客戶端請(qǐng)求參數(shù)(除 nonce)結(jié)合密鑰加密得到 autograph，將 signature 和 autograph 比對(duì)，不相等則認(rèn)為非法請(qǐng)求

但是該方案也有缺點(diǎn)，因?yàn)楫?dāng)次的請(qǐng)求都需要和集合中去搜索匹配，所以該集合不能太大，不然匹配算法特別耗時(shí)，接口性能降低。所以不得不定期刪除部分 nonce 值。但是這樣的情況下，被刪除的 nonce 被利用為重放攻擊，服務(wù)器判定為合法請(qǐng)求。

假設(shè)服務(wù)器只保存24小時(shí)內(nèi)請(qǐng)求的 nonce，該存儲(chǔ)仍舊是一筆不小的開銷。

3.3 基于 timestamp + nonce 的方案

根據(jù) timestamp 和 nonce 各自的特點(diǎn)：timestamp 無法解決60秒內(nèi)的重放請(qǐng)求;nonce 存儲(chǔ)和查找消耗較大。所以結(jié)合2者的特點(diǎn)，便有了 「timestamp + nonce 的防重放方案」。

• 利用 timestamp 解決超過60秒被認(rèn)為非法請(qǐng)求的問題
• 利用 nonce 解決 timestamp 60秒內(nèi)的漏網(wǎng)之魚

步驟：

1. 客戶端將當(dāng)前 timestamp1、隨機(jī)字符串和其他請(qǐng)求參數(shù)，按照密鑰，生成簽名 signature
2. 服務(wù)端收到請(qǐng)求，利用服務(wù)端密鑰，將除 timestamp1、隨機(jī)字符串之外的請(qǐng)求參數(shù)，加密生成簽名 autograph
3. 服務(wù)端對(duì)比 signature 和 autograph，不相等則認(rèn)為非法請(qǐng)求
4. 拿到服務(wù)端時(shí)間戳， timestamp2 - timestamp1 < 60，則判定為一次合法請(qǐng)求，然后保存 nonce
5. 服務(wù)端只保存60秒內(nèi)的 nonce，定時(shí)將集合內(nèi)過期的 nonce 刪除

該集合不應(yīng)該直接操作文件或者數(shù)據(jù)庫，否則服務(wù)端 IO 太多，造成性能瓶頸。可以是 mmap 或者其他內(nèi)存到文件的讀寫機(jī)制。根據(jù)場景可以選擇樂觀鎖、悲觀鎖。

其中有一個(gè) timestamp 的問題，服務(wù)器會(huì)將請(qǐng)求參數(shù)中的 timestamp 判斷差值，其中一個(gè)致命的缺點(diǎn)是服務(wù)器的時(shí)間和客戶端的時(shí)間是存在時(shí)間差的，當(dāng)然你也可以通過校驗(yàn)時(shí)間戳解決此問題。時(shí)間同步請(qǐng)繼續(xù)看下面部分。

四、 計(jì)算機(jī)網(wǎng)絡(luò)時(shí)間同步技術(shù)原理

客戶端和服務(wù)端的時(shí)間同步在很多場景下非常重要，舉幾個(gè)例子，這些場景都是經(jīng)常發(fā)生的。

• 一個(gè)商品秒殺系統(tǒng)。用戶打開頁面，瀏覽各個(gè)類目的商品，商品列表界面右側(cè)和詳情頁都有倒計(jì)時(shí)秒殺功能。用戶在詳情頁加購、下單、結(jié)算。發(fā)現(xiàn)彈出提示“商品庫存不足，請(qǐng)購買同類其他品牌商品”
• 一個(gè)答題系統(tǒng)，題目是該公司核心競爭力。所以有心的程序員為接口設(shè)計(jì)了「防重放」功能。但是前端小哥不給力，接口帶過去的 timestamp 與服務(wù)器不在一個(gè)時(shí)區(qū)，差好幾秒。別有用心的競品公司的爬蟲工程師發(fā)現(xiàn)了該漏洞，爬取了題目數(shù)據(jù)。

所以該現(xiàn)象在計(jì)算機(jī)領(lǐng)域有非常普遍，有解決方案。

如果精度要求不高的情況下：先請(qǐng)求服務(wù)器上的時(shí)間 ServerTime，然后記錄下來，同時(shí)記錄當(dāng)前的時(shí)間 LocalTime1;需要獲取當(dāng)前的時(shí)間時(shí)，用最新的當(dāng)前時(shí)間 (LocalTime2 - LocalTime1 + ServerTime)

拿 iOS 端舉例：

• App 啟動(dòng)后通過接口獲取服務(wù)器時(shí)間 ServerTime，保存本地。并同時(shí)記錄當(dāng)前時(shí)間 LocalTime1
• 需要使用服務(wù)器時(shí)間時(shí)，先拿到當(dāng)前時(shí)間 LocalTime2 - LocalTime1 + ServerTime
• 若獲取服務(wù)器時(shí)間接口失敗，則從緩存中拿到之前同步的結(jié)果(初始的時(shí)間在 App 打包階段內(nèi)置了)
• 使用 NSSystemClockDidChangeNotification 監(jiān)測系統(tǒng)時(shí)間發(fā)生改變，若變化則重新獲取接口，進(jìn)行時(shí)同步

如果需要精度更高，比如 100納秒的情況，則需要使用 NTP(Network Time Protocol)網(wǎng)絡(luò)時(shí)間協(xié)議、PTP (Precision Time Protocol)精確時(shí)間同步協(xié)議了。

網(wǎng)站標(biāo)題：數(shù)據(jù)安全（反爬蟲）之「防重放」策略
文章位置：http://uogjgqi.cn/article/dpjpidg.html