[[191573]]

馬奇諾防線是二戰(zhàn)前法國耗時(shí)十余年修建的防御工事，十分堅(jiān)固，但是由于造價(jià)昂貴，僅修建了法德邊境部分，綿延數(shù)百公里，而法比邊界的阿登高地地形崎嶇，不易運(yùn)動作戰(zhàn)，且比利時(shí)反對在該邊界修建防線，固法軍再次并沒過多防備，滿心期望能夠依靠堅(jiān)固的馬奇諾防線來阻擋德軍的攻勢。沒想到后來德軍避開德法邊境正面，通過阿登高地從防線左翼迂回，繞過了馬奇諾防線，然后就是英法聯(lián)軍的敦克爾克大撤退了。

網(wǎng)站驗(yàn)證碼就如同馬奇諾防線一樣，阻擋了爬蟲工程師的正面進(jìn)攻。

隨著爬蟲和反爬蟲雙方圍繞驗(yàn)證碼的不斷較量，最終導(dǎo)致了驗(yàn)證碼識別難度的不斷上升?，F(xiàn)在復(fù)雜的驗(yàn)證碼長這樣：

面硬剛驗(yàn)證碼，想要識別它，是件挺復(fù)雜的事，涉及到圖像處理技術(shù)：二值化，降噪，切割，字符識別算法：KNN(K鄰近算法)和SVM (支持向量機(jī)算法)，再復(fù)雜點(diǎn)還要借助CNN(卷積神經(jīng)網(wǎng)絡(luò))，還有什么機(jī)器學(xué)習(xí)啥的。

雖然現(xiàn)在有打碼平臺可以解決絕大多數(shù)的驗(yàn)證碼問題，但如果爬取的數(shù)量特別龐大，單純依賴打碼平臺也是不大行得通的，除了成本因素，還有打碼平臺也解決不了的驗(yàn)證碼因素，比如滑動驗(yàn)證碼： 

[[191574]] 

既然正面進(jìn)攻費(fèi)事費(fèi)力，那能不能找到爬蟲工程師眼中的阿登高地繞過驗(yàn)證碼呢?

本文以各地工商網(wǎng)站為例，對常見的驗(yàn)證碼繞過技巧做一個小總結(jié)，順便解密下如何不借助模擬js拖動來繞過滑動驗(yàn)證碼。

各地工商網(wǎng)站(全稱國家企業(yè)信用信息公示系統(tǒng))因?yàn)榘罅科髽I(yè)真實(shí)信息，金融貸款征信等都用得到，天然吸引了很大部分來自爬蟲的火力，因此反爬蟲措施格外嚴(yán)格。一般的網(wǎng)站僅在登錄注冊等環(huán)節(jié)，或者訪問頻繁后才彈出驗(yàn)證碼，而工商網(wǎng)站查詢無需登錄，每查一次關(guān)鍵字就需要一次驗(yàn)證碼。同時(shí)各地工商網(wǎng)站由于各自獨(dú)立開發(fā)，自主采用了各種不同的驗(yàn)證碼機(jī)制，更是給全量爬取的爬蟲增加了更多的障礙。因此，工商網(wǎng)站的驗(yàn)證碼特別具有代表性。

首先，從最簡單的分頁角度入手。

分頁的處理可以放在前端也可以放在后端，如果只放在后端，每次點(diǎn)擊頁碼就需要發(fā)送一次查詢請求，而一次驗(yàn)證碼通常只能服務(wù)于一次請求，再次請求需要獲取新的驗(yàn)證碼，直接觀察翻頁操作是否彈出驗(yàn)證碼輸入框即可判斷是否可以繞過。

如何判斷分頁處理放在前端還是后端的呢?很簡單，F(xiàn)12打開瀏覽器開發(fā)者工具，頁面點(diǎn)下一頁，有新的請求就說明放在后端，反之就是前端。

實(shí)踐發(fā)現(xiàn)，四川和上海的工商網(wǎng)站翻頁都放在后端，且翻頁沒有驗(yàn)證碼輸入框。說明這里的驗(yàn)證碼可以繞過，但是繞過的原理卻有些不同：

對比四川工商網(wǎng)站翻頁前后請求的參數(shù)，除了頁碼參數(shù)外，多了一項(xiàng)：yzmYesOrNo=no。從變量名也猜得到，后端根據(jù)該參數(shù)的值判斷是否需要檢查驗(yàn)證碼。

而上海工商網(wǎng)站的對比結(jié)果發(fā)現(xiàn)，除了頁碼參數(shù)外，少了驗(yàn)證碼字段，因此我們可以大膽猜測：驗(yàn)證碼的校驗(yàn)僅放在了前端，后端沒有做二次校驗(yàn)，從頁面上操作是繞不過的，但是不帶驗(yàn)證碼字段直接向后端發(fā)送請求，數(shù)據(jù)就拿到了。

嚴(yán)格來說，上海工商網(wǎng)站這種算是漏洞，對待這種這種漏洞，爬蟲工程師應(yīng)有的態(tài)度是：悄悄的進(jìn)村，打槍的不要。不過也不要利用的太狠了，筆者實(shí)驗(yàn)時(shí)沒加限制，爬了十萬數(shù)據(jù)后，ip被封了。很長時(shí)間后才解封，同時(shí)頁面改版并修復(fù)了漏洞。

[[191575]] 

其次，觀察目標(biāo)網(wǎng)站是否有多套驗(yàn)證碼。

有些網(wǎng)站不知道出于什么樣的考慮，會在不同的頁面使用不同的驗(yàn)證碼。一旦遇到這種情況，我們可就要撿軟柿子捏了–從簡單的驗(yàn)證碼入手，移花接木，將識別的結(jié)果作為參數(shù)來向后端發(fā)送請求，從而達(dá)到繞過復(fù)雜驗(yàn)證碼的目的。

舉例來說，湖北工商的查詢頁面驗(yàn)證碼是類似下圖的九宮格驗(yàn)證碼：

[[191576]] 

而電子營業(yè)執(zhí)照登陸界面的驗(yàn)證碼是這樣的：

[[191577]] 

即便要識別，也明顯是后者的驗(yàn)證碼要容易些，實(shí)例代碼如下：

再者，可以考慮從數(shù)據(jù)的存儲id入手

專門針對移動端開發(fā)的wap頁面限制一般要少得多。以北京工商網(wǎng)站來說，wap界面不帶驗(yàn)證碼參數(shù)直接發(fā)送請求就可以得到數(shù)據(jù)的，原理類似于上海工商網(wǎng)站，但是其對單個ip日訪問次數(shù)做了嚴(yán)格限制，因此該方式可以用但不好用。

繼續(xù)觀察，以搜索“山水集團(tuán)”為例，從搜索頁到列表頁時(shí)，需要輸入驗(yàn)證碼，而從列表頁進(jìn)入詳情頁的時(shí)候，是不需要驗(yàn)證碼的。最終詳情頁如圖：

通常沒人記得住各地工商網(wǎng)站的網(wǎng)址，我們會去搜索引擎里搜。當(dāng)搜北京企業(yè)信用信息時(shí)，發(fā)現(xiàn)兩個有價(jià)值的結(jié)果，除了國家企業(yè)信用信息公示系統(tǒng)外，還有個北京市企業(yè)信用信息信息網(wǎng)。進(jìn)后者再操作一番可以得到下面的詳情頁:

觀察發(fā)現(xiàn)，企業(yè)id都是相同的，嘿嘿，這不是“兩塊牌子，一套班子”嘛!后者的訪問量要小一些，雖有驗(yàn)證碼，但是可以采用上海工商一樣的方式繞過，只是返回的結(jié)果字段不太符合我們的要求。不過，我們可以去企業(yè)信息網(wǎng)獲得企業(yè)id，再次采用移花接木的方式，去信息公示系統(tǒng)構(gòu)造鏈接獲得最終的詳情頁嘛!

用過數(shù)據(jù)庫同學(xué)都曉得，數(shù)據(jù)庫里的數(shù)據(jù)id，默認(rèn)是自增的。如果有個網(wǎng)站引用的數(shù)據(jù)是xxx.com?id=1234567, 那我們很容易猜得到構(gòu)造類似1234568這樣的id去嘗試!通常，使用這種id規(guī)律能夠輕易猜出來的網(wǎng)站并不多，但不代表沒有。比如甘肅省工商網(wǎng)站，結(jié)果頁是拿企業(yè)注冊號來查詢的。

***，談?wù)劵瑒域?yàn)證碼。

目前，工商網(wǎng)站已經(jīng)全面改版，全部采用了滑動驗(yàn)證碼，上面絕大多數(shù)思路都失效了。對于滑動驗(yàn)證碼，網(wǎng)上能搜到的解決方案基本都是下載圖片，還原圖片，算出滑動距離，然后模擬js來進(jìn)行拖動解決，我們來看下能否不模擬拖動來解決這個問題。

以云南工商網(wǎng)站為例，首先抓包看過程。

1. http://yn.gsxt.gov.cn/notice/pc-geetest/register?t=147991678609，response：

2. 下載驗(yàn)證碼圖片

3. http://yn.gsxt.gov.cn/notice/pc-geetest/validate， post如下數(shù)據(jù)：

4. http://yn.gsxt.gov.cn/notice/search/ent_info_list，post如下數(shù)據(jù)：

仔細(xì)分析，我們發(fā)現(xiàn)兩處疑點(diǎn)：

1. ***步并沒有返回需要下載的圖片地址，那么前端怎么知道要下載哪些圖片?

2. 第三步驗(yàn)證時(shí)，并沒有告知后端下載了那些圖片，后端是怎么驗(yàn)證post過去的數(shù)據(jù)是有效性的?

仔細(xì)閱讀前端混淆的js代碼，我們發(fā)現(xiàn)前端數(shù)據(jù)處理過程是這樣的：

1. 從0到6(不含)中取隨機(jī)整數(shù)，賦值給d， d=5;

2. 從0到300(不含)中取隨機(jī)整數(shù)，賦值給e， e=293;

3. 將d轉(zhuǎn)化為字符串并作MD5加密，加密字符串取前9位賦值給f， f=’e4da3b7fb’;

4. 將e轉(zhuǎn)化為字符串并作MD5加密，加密字符串從第11位開始取9位賦值給g, g=’43be4f209’;

5. 取f的偶數(shù)位和g的奇數(shù)位組成新的9位字符串給h, h=’e3de3f70b’;

6. 取h的后4位與200做MOD運(yùn)算，其結(jié)果小于40，則取40，否則取其本身賦值給x，x=51;

7. 取[x-3, x+3]以內(nèi)隨機(jī)數(shù)賦值給c，c=51;

8. 分別取c,d,e跟challenge做t加密(t(c,challenge), t(d, challenge), t(e,challenge))并用(_)拼接即為geetest_validate, ‘9ccccc997288_999c9ccaa83_999cc9c9999990d’

這里f, g參數(shù)決定了下載圖片地址：

而x為滑塊拖動的橫向偏移量，至此解答了疑問1中圖片下載地址怎么來的問題。

前邊提到的t加密過程是這樣的：

t(a,b)，此處以a=51演示

1. challenge為34位16進(jìn)制字符串，取前32位賦值給prefix，后2位賦值給suffix，prefix=’34173cb38f07f89ddbebc2ac9128303f’, suffix=’a8′

2. prefix去重并保持原順序，得到列表 [‘3’, ‘4’, ‘1’, ‘7’, ‘c’, ‘b’, ‘8’, ‘f’, ‘0’, ‘9’, ‘d’, ‘e’, ‘2’, ‘a’]

3. 將2中列表循環(huán)順序放入包含5個子列表的列表中，得到random_key_list： [[‘3’, ‘b’, ‘d’], [‘4’, ‘8’, ‘e’], [‘1’, ‘f’, ‘2’], [‘7’, ‘0’, ‘a’], [‘c’, ‘9’]]

4. 將suffix字符串(16進(jìn)制)逐位轉(zhuǎn)化為10進(jìn)制，得到[10, 8]

6. 將4中列表逐位與[36,0]做乘法和運(yùn)算并與a的四舍五入結(jié)果相加， n= 51 + 36*10 + 0*8=419

7. q=[1,2,5,10,50], 用q對n做分解(n=50*13+10*0+5*1+2*1+1*1)，將其因數(shù)倒序賦值給p，p=[0,2,1,1,8]

8. 從random_key_list右側(cè)開始隨機(jī)取值，次數(shù)為p中數(shù)值，拼成字符串sub_key，sub_key=’9ccccc997288′

至此，我們完成了整個分析過程，我們又有了新發(fā)現(xiàn)：

1. 按照前邊的抓***程，其實(shí)不需要真的下載圖片，只需執(zhí)行1、3、4步就可以得到目標(biāo)數(shù)據(jù)了。步驟1也可以不要，只需3、4即可，但是少了步驟1， 我們還需要額外請求一次cookie，所以還是保留1, 這樣也偽裝的像一點(diǎn)嘛。

2. 相同的challenge，每次運(yùn)算都可以得出不同的validate和seccode，那么問題來了：到底服務(wù)端是怎么根據(jù)challenge驗(yàn)證其他數(shù)據(jù)是否有效呢?

總結(jié)一下，對于驗(yàn)證碼，本文只是提供了一種新的思路，利用了網(wǎng)站開發(fā)過程中的一點(diǎn)小疏漏，而***的滑動驗(yàn)證碼也只是分析了offline模式的驗(yàn)證方法。不要指望所有驗(yàn)證碼都可以能繞過，沒有阿登高地，二戰(zhàn)德國就不打法國了么?只要覺得有價(jià)值，即使正面面對驗(yàn)證碼，作為爬蟲工程師建議也就一句話：不要慫，就是干!