尋找阿登高地——爬蟲工程師如何繞過驗證碼
馬奇諾防線是二戰(zhàn)前法國耗時十余年修建的防御工事，十分堅固，但是由于造價昂貴，僅修建了法德邊境部分，綿延數(shù)百公里，而法比邊界的阿登高地地形崎嶇，不易運動作戰(zhàn)，且比利時反對在該邊界修建防線，固法軍再次并沒過多防備，滿心期望能夠依靠堅固的馬奇諾防線來阻擋德軍的攻勢。沒想到后來德軍避開德法邊境正面，通過阿登高地從防線左翼迂回，繞過了馬奇諾防線，然后就是英法聯(lián)軍的敦克爾克大撤退了。
網(wǎng)站驗證碼就如同馬奇諾防線一樣，阻擋了爬蟲工程師的正面進攻。
隨著爬蟲和反爬蟲雙方圍繞驗證碼的不斷較量，最終導(dǎo)致了驗證碼識別難度的不斷上升。現(xiàn)在復(fù)雜的驗證碼長這樣：
面硬剛驗證碼，想要識別它，是件挺復(fù)雜的事，涉及到圖像處理技術(shù)：二值化，降噪，切割，字符識別算法：KNN(K鄰近算法)和SVM (支持向量機算法)，再復(fù)雜點還要借助CNN(卷積神經(jīng)網(wǎng)絡(luò))，還有什么機器學(xué)習(xí)啥的。
雖然現(xiàn)在有打碼平臺可以解決絕大多數(shù)的驗證碼問題，但如果爬取的數(shù)量特別龐大，單純依賴打碼平臺也是不大行得通的，除了成本因素，還有打碼平臺也解決不了的驗證碼因素，比如滑動驗證碼：
既然正面進攻費事費力，那能不能找到爬蟲工程師眼中的阿登高地繞過驗證碼呢?
本文以各地工商網(wǎng)站為例，對常見的驗證碼繞過技巧做一個小總結(jié)，順便解密下如何不借助模擬js拖動來繞過滑動驗證碼。
各地工商網(wǎng)站(全稱國家企業(yè)信用信息公示系統(tǒng))因為包含大量企業(yè)真實信息，金融貸款征信等都用得到，天然吸引了很大部分來自爬蟲的火力，因此反爬蟲措施格外嚴格。一般的網(wǎng)站僅在登錄注冊等環(huán)節(jié)，或者訪問頻繁后才彈出驗證碼，而工商網(wǎng)站查詢無需登錄，每查一次關(guān)鍵字就需要一次驗證碼。同時各地工商網(wǎng)站由于各自獨立開發(fā)，自主采用了各種不同的驗證碼機制，更是給全量爬取的爬蟲增加了更多的障礙。因此，工商網(wǎng)站的驗證碼特別具有代表性。
首先，從最簡單的分頁角度入手。
分頁的處理可以放在前端也可以放在后端，如果只放在后端，每次點擊頁碼就需要發(fā)送一次查詢請求，而一次驗證碼通常只能服務(wù)于一次請求，再次請求需要獲取新的驗證碼，直接觀察翻頁操作是否彈出驗證碼輸入框即可判斷是否可以繞過。
如何判斷分頁處理放在前端還是后端的呢?很簡單，F(xiàn)12打開瀏覽器開發(fā)者工具，頁面點下一頁，有新的請求就說明放在后端，反之就是前端。
實踐發(fā)現(xiàn)，四川和上海的工商網(wǎng)站翻頁都放在后端，且翻頁沒有驗證碼輸入框。說明這里的驗證碼可以繞過，但是繞過的原理卻有些不同：
對比四川工商網(wǎng)站翻頁前后請求的參數(shù)，除了頁碼參數(shù)外，多了一項：yzmYesOrNo=no。從變量名也猜得到，后端根據(jù)該參數(shù)的值判斷是否需要檢查驗證碼。
而上海工商網(wǎng)站的對比結(jié)果發(fā)現(xiàn)，除了頁碼參數(shù)外，少了驗證碼字段，因此我們可以大膽猜測：驗證碼的校驗僅放在了前端，后端沒有做二次校驗，從頁面上操作是繞不過的，但是不帶驗證碼字段直接向后端發(fā)送請求，數(shù)據(jù)就拿到了。
嚴格來說，上海工商網(wǎng)站這種算是漏洞，對待這種這種漏洞，爬蟲工程師應(yīng)有的態(tài)度是：悄悄的進村，打槍的不要。不過也不要利用的太狠了，筆者實驗時沒加限制，爬了十萬數(shù)據(jù)后，ip被封了。很長時間后才解封，同時頁面改版并修復(fù)了漏洞。
其次，觀察目標(biāo)網(wǎng)站是否有多套驗證碼。
有些網(wǎng)站不知道出于什么樣的考慮，會在不同的頁面使用不同的驗證碼。一旦遇到這種情況，我們可就要撿軟柿子捏了–從簡單的驗證碼入手，移花接木，將識別的結(jié)果作為參數(shù)來向后端發(fā)送請求，從而達到繞過復(fù)雜驗證碼的目的。
舉例來說，湖北工商的查詢頁面驗證碼是類似下圖的九宮格驗證碼：
而電子營業(yè)執(zhí)照登陸界面的驗證碼是這樣的：
即便要識別，也明顯是后者的驗證碼要容易些，實例代碼如下：
再者，可以考慮從數(shù)據(jù)的存儲id入手
專門針對移動端開發(fā)的wap頁面限制一般要少得多。以北京工商網(wǎng)站來說，wap界面不帶驗證碼參數(shù)直接發(fā)送請求就可以得到數(shù)據(jù)的，原理類似于上海工商網(wǎng)站，但是其對單個ip日訪問次數(shù)做了嚴格限制，因此該方式可以用但不好用。
繼續(xù)觀察，以搜索“山水集團”為例，從搜索頁到列表頁時，需要輸入驗證碼，而從列表頁進入詳情頁的時候，是不需要驗證碼的。最終詳情頁如圖：
通常沒人記得住各地工商網(wǎng)站的網(wǎng)址，我們會去搜索引擎里搜。當(dāng)搜北京企業(yè)信用信息時，發(fā)現(xiàn)兩個有價值的結(jié)果，除了國家企業(yè)信用信息公示系統(tǒng)外，還有個北京市企業(yè)信用信息信息網(wǎng)。進后者再操作一番可以得到下面的詳情頁:
觀察發(fā)現(xiàn)，企業(yè)id都是相同的，嘿嘿，這不是“兩塊牌子，一套班子”嘛!后者的訪問量要小一些，雖有驗證碼，但是可以采用上海工商一樣的方式繞過，只是返回的結(jié)果字段不太符合我們的要求。不過，我們可以去企業(yè)信息網(wǎng)獲得企業(yè)id，再次采用移花接木的方式，去信息公示系統(tǒng)構(gòu)造鏈接獲得最終的詳情頁嘛!
用過數(shù)據(jù)庫同學(xué)都曉得，數(shù)據(jù)庫里的數(shù)據(jù)id，默認是自增的。如果有個網(wǎng)站引用的數(shù)據(jù)是xxx.com?id=1234567, 那我們很容易猜得到構(gòu)造類似1234568這樣的id去嘗試!通常，使用這種id規(guī)律能夠輕易猜出來的網(wǎng)站并不多，但不代表沒有。比如甘肅省工商網(wǎng)站，結(jié)果頁是拿企業(yè)注冊號來查詢的。
***，談?wù)劵瑒域炞C碼。
目前，工商網(wǎng)站已經(jīng)全面改版，全部采用了滑動驗證碼，上面絕大多數(shù)思路都失效了。對于滑動驗證碼，網(wǎng)上能搜到的解決方案基本都是下載圖片，還原圖片，算出滑動距離，然后模擬js來進行拖動解決，我們來看下能否不模擬拖動來解決這個問題。
以云南工商網(wǎng)站為例，首先抓包看過程。
1. http://yn.gsxt.gov.cn/notice/pc-geetest/register?t=147991678609，response：
2. 下載驗證碼圖片
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ù)：
仔細分析，我們發(fā)現(xiàn)兩處疑點：
1. ***步并沒有返回需要下載的圖片地址，那么前端怎么知道要下載哪些圖片?
2. 第三步驗證時，并沒有告知后端下載了那些圖片，后端是怎么驗證post過去的數(shù)據(jù)是有效性的?
仔細閱讀前端混淆的js代碼，我們發(fā)現(xiàn)前端數(shù)據(jù)處理過程是這樣的：
1. 從0到6(不含)中取隨機整數(shù)，賦值給d， d=5;
2. 從0到300(不含)中取隨機整數(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運算，其結(jié)果小于40，則取40，否則取其本身賦值給x，x=51;
7. 取[x-3, x+3]以內(nèi)隨機數(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進制字符串，取前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進制)逐位轉(zhuǎn)化為10進制，得到[10, 8]
6. 將4中列表逐位與[36,0]做乘法和運算并與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è)開始隨機取值，次數(shù)為p中數(shù)值，拼成字符串sub_key，sub_key=’9ccccc997288′
至此，我們完成了整個分析過程，我們又有了新發(fā)現(xiàn)：
1. 按照前邊的抓***程，其實不需要真的下載圖片，只需執(zhí)行1、3、4步就可以得到目標(biāo)數(shù)據(jù)了。步驟1也可以不要，只需3、4即可，但是少了步驟1， 我們還需要額外請求一次cookie，所以還是保留1, 這樣也偽裝的像一點嘛。
2. 相同的challenge，每次運算都可以得出不同的validate和seccode，那么問題來了：到底服務(wù)端是怎么根據(jù)challenge驗證其他數(shù)據(jù)是否有效呢?
總結(jié)一下，對于驗證碼，本文只是提供了一種新的思路，利用了網(wǎng)站開發(fā)過程中的一點小疏漏，而***的滑動驗證碼也只是分析了offline模式的驗證方法。不要指望所有驗證碼都可以能繞過，沒有阿登高地，二戰(zhàn)德國就不打法國了么?只要覺得有價值，即使正面面對驗證碼，作為爬蟲工程師建議也就一句話：不要慫，就是干!
