網絡爬蟲-2018個人總結

概述


忙裏偷閒,趁着元旦休息的這幾天,在2018年的最後一天,總結一下自己在這一年遇到過的多多少少的坑以及一些心得體會吧。
粗略算下來,從事爬蟲工程師這個崗位也算是一年有餘了吧,從一個毛髮旺盛的小夥,到一個即將面對禿頭危機的油膩大叔,也只花了一年的時間~
在這裏插入圖片描述

挖坑


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

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

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請求頭,可以直接打開chromeDEVTool,查看Networktap,就可以查看到相關的請求頭參數。
另外說一下,總結了幾種是獲取不到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)另一位大佬

(二)召集全公司,在你們公司所有云服務器上部署好httpss代理,這樣有兩點好處,一方面公司越大,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加油吧

向大佬之路邁進

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章