偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

數(shù)據(jù)安全(反爬蟲)之「防重放」策略

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

 [[375322]]

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

一、 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é)議了。

原文鏈接:https://segmentfault.com/a/1190000021922705

 

責(zé)任編輯:武曉燕 來源: Segmentfault
相關(guān)推薦

2014-09-22 10:40:55

2017-04-27 20:45:48

爬蟲反爬蟲

2017-05-15 10:39:48

爬蟲應(yīng)對(duì)機(jī)制

2024-10-28 17:10:52

2022-11-24 10:24:32

2010-09-30 09:11:01

2010-09-30 08:27:48

2018-02-07 04:47:17

2009-08-19 10:34:16

反爬蟲

2022-09-14 23:06:45

2011-07-06 14:28:32

2024-01-10 08:03:50

數(shù)據(jù)安全網(wǎng)絡(luò)安全

2011-06-20 13:29:44

2015-09-17 10:30:45

2015-09-25 10:46:48

2016-10-13 15:51:50

2022-09-20 07:02:20

網(wǎng)絡(luò)爬蟲反爬蟲

2009-09-10 09:26:30

2016-03-19 15:43:12

2010-05-19 18:42:23

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)