天天看點

網絡爬蟲-2018個人總結概述挖坑1 寫在開頭2 反爬分類以及對應解決方案3 大V推薦寫給你和我的一些建議和忠告

概述

忙裡偷閑,趁着元旦休息的這幾天,在2018年的最後一天,總結一下自己在這一年遇到過的多多少少的坑以及一些心得體會吧。

粗略算下來,從事爬蟲工程師這個崗位也算是一年有餘了吧,從一個毛發旺盛的小夥,到一個即将面對秃頭危機的油膩大叔,也隻花了一年的時間~

網絡爬蟲-2018個人總結概述挖坑1 寫在開頭2 反爬分類以及對應解決方案3 大V推薦寫給你和我的一些建議和忠告

挖坑

一個人在反反爬蟲的路上真的很難☁️⚡️?❄️,不過這裡有一群志同道合的我們☔️☀️

1 . ☀️反爬分類以及解決方案

  • 1.1 消息頭鑒别
    • 1.1.1 Referer鑒别
      • 1.1.1.1 反爬原理
      • 1.1.1.2 真實場景還原
      • 1.1.1.3 解決方案
    • 1.1.2 UserAgent鑒别
      • 1.1.2.1 反爬原理
      • 1.1.2.2 真實場景還原
      • 1.1.2.3 解決方案
    • 1.1.3 Cookie鑒别
      • 1.1.3.1 反爬原理
      • 1.1.3.2 真實場景還原
      • 1.1.3.3 解決方案
    • 1.1.4 基于使用者會話(Session)的反爬
      • 1.1.4.1 場景
      • 1.1.4.2 原理
      • 1.1.4.3 解決方案
  • 2.2 IP判别
    • 2.2.1 相同IP鑒别
      • 2.2.1.1 反爬原理
      • 2.2.1.2 真實場景還原
      • 2.2.1.3 解決方案
  • 2.3 請求參數、主體判别
    • 2.3.1 請求參數鑒别(參數保護)
      • 2.3.1.1 場景
      • 2.3.1.2 原理
      • 2.3.1.3 解決方案
    • 2.3.2 請求主體鑒别
      • 2.3.2.1 反爬原理
      • 2.3.2.2 真實場景還原
      • 2.3.2.3 解決方案
  • 2.4 驗證碼判定
    • 2.4.1 圖檔驗證碼
      • 2.4.1.1 反爬原理
      • 2.4.1.2 真實場景還原
      • 2.4.1.3 解決方案
    • 2.4.2 語音驗證碼
      • 2.4.2.1 反爬原理
      • 2.4.2.2 真實場景還原
      • 2.4.2.3 解決方案
    • 2.4.3 極驗驗證碼
      • 2.4.3.1 反爬原理
      • 2.4.3.2 真實場景還原
      • 2.4.3.3 解決方案
    • 2.4.4 短信驗證碼
      • 2.4.4.1 鑒别原理
      • 2.4.4.2 真實場景還原
      • 2.4.4.3 解決方案
  • 2.5 使用者行為判别
    • 2.5.1 頁面行為檢測
      • 2.5.1.1 反爬原理
      • 2.5.1.2 真實場景還原
      • 2.5.1.3 解決方案
    • 2.5.2 浏覽器指紋檢測
      • 2.5.2.1 反爬原理
      • 2.5.2.2 真實場景還原
      • 2.5.2.3 解決方案
  • 2.6 前端反調試Debug
    • 2.6.1 死循環Debug攔截DevTools
      • 2.6.1.1 反爬原理
      • 2.6.1.2 真實場景還原
      • 2.6.1.3 解決方案
    • 2.6.2 反無頭浏覽器(headless)
      • 2.6.2.1 場景
      • 2.6.2.2 原理
      • 2.6.2.3 解決方案
    • 2.6.3 前端代碼混淆
      • 2.6.3.1 場景
      • 2.6.3.2 原理
      • 2.6.3.3 解決方案
  • 2.7 APP驗簽
    • 2.7.1 代碼混淆
      • 2.7.1.1 反爬原理
      • 2.7.1.2 真實場景還原
      • 2.7.1.3 解決方案
  • 2.8 反無頭浏覽器(Headless)

3 . 大V推薦

1 寫在開頭

1.1 項目初衷

建立這個項目的初衷是有幾點在日常工作和學習中的感悟:
    (1)接觸到的反爬場景少,預先的知識儲備不足,真正面對的時候學習周期長,解決難題時間長以緻項目延期。
    (2)想要抽空學習,卻不知道從哪裡入手,沒有合适的反爬的社群來交流讨論經驗,沒有完整可用的案例來輔助學習,網上的案例簡單并且基礎,不适合想要深入學習的人。
    (3)追求挑戰性,這點我想是很多爬蟲愛好者的“天性”,正如安全圈子一樣,大家總用“英雄主義”的理想,想着沒有攻克的難關。是以,就需要新的“難關”抛出,于是,就希望建立這個項目以及相關小組能夠幫助大家實作自己的“英雄夢”。
           

1.2 項目介紹

項目其實很簡單,我們會主要分為兩個部分,也就是大家通常學習的順序 - “理論”和“實戰”,
   還有一些我們小組自研的開源庫,幫助大家平常減少重複造輪子。
   
   理論方面: 我們會總結一下常見的反爬類型以及對應的解決方案、實際案例。
   
   實際案例方面:我們會結合真實的網站,詳細的針對其反爬手段來進行分析。 
           

1.3 加入我們

我們的想法很簡單:“正如沒有穿不透的牆,也沒有反不了的反爬”
加入我們,反“反爬”開源小組,可以來fork --> https://github.com/AntiCrawlerSolution
           

1.4 感謝

感謝`@cr`大佬的内容送出 AntiCrawlerSolution小組所有成員的貢獻
           

2 反爬分類以及對應解決方案

2.1 消息頭鑒别

2.1.1 Referer鑒别

2.1.1.1 字段含義

在HTTP協定中,存在一個

Referer

字段,詳情可見WIKI,當浏覽器(或者模拟浏覽器行為)向

Web

伺服器發送請求的時候,

頭資訊裡有包含

Referer

,這個字段主要有三方面的作用,一是常用來作為網站的流量來源的統計,二是可以用來做防盜鍊的行為,比如我們的圖檔伺服器隻允許我們自己的網站域名來

通路,其他的一概拒絕,第三也是很重要的(ps: 也可以說經常被人利用的一點)就是用來防止惡意請求,很多網站的某些重要頁面也會使用這樣的機制來識别一些爬蟲。

2.1.1.2 真實場景還原

2.1.1.3 解決方案

這個問題的解決方案就是我們需要僞造一個使用者的

HTTP

請求頭,可以直接打開

chrome

DEVTool

,檢視

Network

tap

,就可以檢視到相關的請求頭參數。

另外說一下,總結了幾種是擷取不到

Referer

字段的情況:

(1)在浏覽器内直接敲URL

(2)windows桌面上的超連結圖示

(3)浏覽器内書簽

(4)第三方軟體(如Word,Excel等)内容中的連結

(5)SSL認證網站跳入

(6)http://example.com/“> meta頁面設定自動跳轉時,在example.com将取不到REFERER URL

(7)使用JavaScript的Location.href或者是Location.replace()

2.1.2 UserAgent鑒别

2.1.2.1 消息頭鑒别

User Agent

中文名為使用者代理,簡稱

UA

,它是一個特殊字元串頭,使得伺服器能夠識别客戶使用的作業系統及版本、CPU 類型、浏覽器及版本、浏覽器渲染引擎、浏覽器語言、浏覽器插件等,

為什麼會有這個字段的鑒别呢,一方面是通過這個字段來判斷某個時間段内某個機器的大量請求,另一方面大概就是很多爬蟲架構或者各個語言請求庫直接通路網站的話

UA

字段都會顯示語言的版本或者

是架構的版本,是以這個參數還是會過濾很多小白爬蟲。

2.1.2.2 真實場景還原

2.1.2.3 解決方案

這個問題的解決方案也是通過使用僞造

HTTP

請求頭的方式來僞造你的請求,參考資源有幾下幾種:

常用的請求頭

很多人可能都不太了解

UA

頭裡面的各個子參數的含義,下面這個網站可以讓大家來了解一下

UA解析

2.1.3 Cookie鑒别

2.1.3.1 消息頭鑒别

反爬界最喜歡用的兩種反爬手段其一,

Cookie

鑒别大多會出現在某些需要登入的網站,因為此類網站的資訊都是高度資訊化或者原創化,是以不想輕易的被爬取和提高使用者依賴性,他們就會需要使用者登入,

這個時候我們就必須要登入來擷取登入之後使用者的

Cookie

,這個字段是用來識别使用者的身份的,一般服務端也會根據這個字段會使用者展示不同的頁面,是以可能你是否使用

Cookie

顯示的是不同的頁面。

2.1.3.2 真實場景還原

2.1.3.3 解決方案

解決

Cookie

的方法最簡單的還是僞造請求頭,也就是需要我們先登入網站,然後擷取的到具體的

Cookie

的值,一般來說

Cookie

的有效期都會有一定的時間,過期之後我們再按

之前的方法擷取

Cookie

,這一部分會涉及到一部分自動化登入的原理,這個我們會結合實際的場景來談,這一部分我們需要知道僞造請求頭就能繞過

Cookie

鑒别。

我們這有幾種方法告訴大家怎麼分析

Cookie

:

(1) 删除

Cookie

看是否正常,另外關于

Cookie

的反爬我們需要把每次環境給配置好,也就是為了防止一些網站根據我們之前的曆史登入賬号來判斷我們是否具有反爬特征,比如我用浏覽器

頻繁新增賬號并登入,這樣的話會在曆史紀錄,賬号記錄中留下

痕迹

,是以我們每次測試最好使用浏覽器的

隐私模式

,因為這種模式都會有一個

DNT

頭,也就是拒絕對方網站對于己方的追蹤,

另外,我們在切換賬号的時候需要清空曆史記錄。

(2)我們需要拿多個頁面測試,也就是我們通路多個頁面,看看

Cookie

的值是否是變化的,如果是不變的話,可能它隻是一個登入的憑證,如果它是變化的,我們就得具體看看是哪個參數變化的具體分析了。

(3)找到Cookie中比較特别的詞(至于什麼是特别的詞,需要大家用正常人的智商去判斷)。用這個詞去主要的Javascript檔案中搜尋。一般來說會找到檔案中具體是哪一句設定的,如果這個邏輯看着很複雜,可以在這一句打斷點調試來判斷這個Cookie到底如何生成的。

(4)終極方案Break-on-Access

關于這個Chrome Snippets怎麼使用,大家直接參考這個這個Github的連結,解釋的挺清楚。有了這個工具,我們調用一下:

breakOn(document, ‘cookie’);

就可以在任何語句修改Cookie的時候,進入斷點。再通過單點調試,逐漸揭開反爬工程師險惡的面紗了。

2.1.4 基于使用者會話(Session)的反爬

2.1.4.1 場景

一般中小網站為了減輕資料庫的壓力,不會把請求次數記錄在資料庫中,因為每次請求都得update,對資料庫壓力相對較大,這類站點會選擇把請求次數記錄在會話資料中。

2.1.4.2 原理

在使用者session中記錄請求頻次,同時記錄封禁次數,單次封禁時間可以跟封禁次數指數相關,以此限制單賬戶的請求頻率。

2.1.4.3 解決方案

這種方式的弱點在于,會話資料隻對一次會話有效,通常使用者通路web伺服器時,伺服器會頒發一個session_id,通過cookie發送給使用者,使用者隻要觸發封禁前清空cookie,重建立立會話就可以了。對于不需要登入的場景,還可以不帶cookie(session_id)去請求伺服器。

2.2 IP判别

2.2.1 相同IP鑒别

2.2.1.1 消息頭鑒别

反爬界最喜歡用的兩種反爬手段其二,說到

IP

來反爬,真的讓一些小公司或者說一些小的爬蟲小組無可奈何,特别是需要爬的網站需要高頻通路,并且對于

IP

審查很嚴格的時候,

IP

成了一個難題

2.2.1.2 真實場景還原

2.2.1.3 解決方案

目前解決

IP

短缺的問題就是維護

IP

池,是以我們的方案就圍繞

IP

池來說,

(一)開源

IP

池,也就說我們可以爬取一些代理

IP

的網站,因為這類網站都會有一些免費的可試用的

IP

,具體情況可以參考[代理ip網站情況分析]https://www.jianshu.com/p/6e5f35aa0e04,

IP

池的實作方法大家可以參考幾個大佬自己做的

IP

池:

(1)七夜大佬

(2)另一位大佬

(二)召集全公司,在你們公司所有雲伺服器上部署好

http

ss

代理,這樣有兩點好處,一方面公司越大,

IP池

越大,另一方面,其實你們的伺服器上部署的正式的網站、APP服務也會讓你們的

IP

變得比别人穩定、可靠,稍微降低被封的風險,不過要全公司都這麼搞,有點麻煩。

(三)去我們第一步說的那些代理網站買服務,不過得"擦亮眼睛看好了"

2.3 請求參數、主體判别

2.3.1 請求參數鑒别(參數保護)

2.3.1.1 場景

web的參數保護,主要用于表單防護,特别是注冊和登入表單的防護,我們知道有效提供攻擊成本的手段主要是基于IP的計數和基于使用者的計數,其中基于使用者的計數,攻擊者會批量新增賬號,是以注冊和登入表單的保護變得尤其重要

2.3.1.2 原理

參數保護主要依賴參數加密和混淆

參數加密主要是用JS加密表單需要送出的資料,後端解密這個資料。

加密方式很多,有單個參數加密的,也有所有參數整體加密的。

如果是單個參數加密的,不僅可以加密參數值,還可以加密參數名,還可以随機填充一些隐藏的input。

表單裡的input數量随機,參數值随機,參數名也是随機的。然後利用JS控制DOM顯示出真正有效的input。

這些JS代碼通常會被保護起來。見前端代碼混淆

2.3.1.3 解決方案

對于非動态的表單,可以逆向JS代碼。

對于動态的表單,通常需要上headless浏覽器

PS: 關于

headless

浏覽器,現在主要推薦

google-chromium

可以使用

Remote debugging protocol

以及其相對應的高層封裝puppeteer

2.3.2 請求主體鑒别

2.3.2.1 消息頭鑒别

2.3.2.2 真實場景還原

2.3.2.3 解決方案

2.4 驗證碼判定

2.4.1 圖檔驗證碼

2.4.1.1 反爬原理

2.4.1.2 真實場景還原

2.4.1.3 解決方案

圖檔驗證碼目前算是最簡單,最常見的驗證碼了,是以對于它的破解手段也是比較常見,“爛大街”了,圖檔驗證碼的難度系數劃分大緻是由其圖檔中圖案的複雜程度來劃分,比如:

1.數字類或字母類

2.數字字母混合類

3.數字字母混合亂序類

4.物品識别類

對于不同難度的有不同種的解決方案,之後會詳細補充。

2.4.2 語音驗證碼

2.4.2.1 反爬原理

2.4.2.2 真實場景還原

2.4.2.3 解決方案

2.4.3 極驗驗證碼

2.4.3.1 反爬原理

2.4.3.2 真實場景還原

2.4.3.3 解決方案

2.4.4 短信驗證碼

2.4.4.1 鑒别原理

一般短信都會需要一個手機号,鑒别的原理也是基于此,這類鑒别方式也是将我們之前的

Cookie

鑒别結合在一起,首先需要能有接收驗證碼的手機,新增賬號,之後才會輪到自動化登入那一步,

是以我們要想注冊大量手機号,類似“刷單”,我們就需要大量手機号。

2.4.4.2 真實場景還原

2.4.4.3 解決方案

這個問題的解決方法大體如上面的圖檔驗證碼那樣,算是比較普遍了,因為現在有很多手機接碼平台,類似易碼這樣算是比較穩定的平台,大概資費在0.1元/條這樣,原理大家可以自行百度“貓池”,之後會給大家一個大緻的分析。

2.5 使用者行為判别

2.5.1 頁面行為檢測

2.5.1.1 消息頭鑒别

2.5.1.2 真實場景還原

2.5.1.3 解決方案

2.5.2 浏覽器指紋檢測

2.5.2.1 消息頭鑒别

2.5.2.2 真實場景還原

2.5.2.3 解決方案

2.6 前端防護

2.6.1 死循環Debug攔截DevTools

2.6.1.1 消息頭鑒别

2.6.1.2 真實場景還原

2.6.1.3 解決方案

2.6.2 反無頭浏覽器(Headless)

2.6.2.1 場景

2.6.2.2 原理

2.6.2.3 解決方案

2.6.3 前端代碼混淆

2.6.3.1 場景

2.6.3.2 原理

2.6.3.3 解決方案

2.7 APP驗簽

2.7.1 代碼混淆

2.7.1.1 消息頭鑒别

2.7.1.2 真實場景還原

2.7.1.3 解決方案

3 大V推薦

脫殼破解相關:吾愛破解

寫給你和我的一些建議和忠告

《刑法》第 285 條,非法擷取計算機資訊系統資料罪。

擷取該計算機資訊系統中存儲、處理或者傳輸的資料,或者對該計算機資訊系統實施非法控制,

處三年以下有期徒刑或者拘役,并處或者單處罰金; 最高處七年有期徒刑并處罰金。

《刑法》第285條是對爬取資料的主要定罪依據,有興趣可以去查下中華人民共和國刑法。
           

作為一名合格的爬蟲coder,還是必須得對一些涉及到的法律知識有所了解,該爬的,不該爬的,自己心裡要有數,不要被利益蒙蔽了頭腦。

寫網絡爬蟲的法律邊界 有興趣的童鞋也可以看一看 猿人學python裡面的一些案例 一些非法入侵的行為 我們一定是要杜絕的

ending

2019加油吧

向大佬之路邁進

繼續閱讀