上一篇文章《selenium的檢測與突破》講過瞭如果繞過對於webdriver的檢測。

接下來就可以登陸了嗎？別高興太早：

無論我使用find_element_by_id還是find_element_by_xpath，當輸入密碼時候都會出現「哎呀出錯」的滑動驗證碼。想必大家都會被此困惑。

於是乎，我通過邪惡F12 發現每當用戶名發生變更之後，點擊密碼輸入框，就會出現一個POST請求，兩個參數：一個username，另一個是一大串的ua，返回一個{"needcode":"True"} ，誒？好像懂了一些，於是，測試不使用selenium的正常登陸，返回的值的False。嗯，又懂了一些。

那麼問題來了，這一大串ua怎麼搞？

If you can ,受小弟一拜!

於是，我嘗試使用上文的代碼注入思想，能不能偷梁換柱，將True改為False，對不起，沒好使。

經查閱資料，這一大串ua，不僅包括著瀏覽器指紋，滑鼠軌跡，等等等，並且，演算法不止一套。

最後，還是老老實實盡量去模擬真人操作吧：

控制變數法：

第一回合：

通過find_by_element_輸入賬號密碼後，並且sleep隨機時間，手動滑動驗證碼，無論怎麼滑，刷新多少次都是「哎呀出錯了」→刷新，繼續手動輸入賬號密碼，手動滑動驗證碼→死循環——很委婉的驗證失敗。

所以，那些網上說滑動驗證碼，要分段，或者通過速度曲線去滑，都是次要的。因為已經檢測出來是機器人， 只是通過這種方式很委婉的告訴你被反爬了，敗北。

第二回合：

把『find_element_by_』統統注釋掉，採用ActionChains，並且來一些障眼法——做一些滑鼠移動的假動作，敗北。

第三回合：

僅僅通過selenium+mitmproxy+chromedriver 去啟動瀏覽器，然後手動去輸入賬號密碼，哎？沒彈驗證碼，並且點擊登錄，成功了？？？？

因此我斷定，這第二關是行為反爬

繼續科學上網，其實chromedriver會將下圖中的JavaScript文件注入瀏覽器。

於是我的猜想：

1.通過sleep隨機時間，排除了操作過快的原因。

2.find_element_by和ActionChains都是會被檢測的。好像是selenium會開啟一個本地代理，所有的瀏覽器自動操作都會用這個代理進行，find_element方法就與selenium代理進行了通信，不知道js是怎麼知道selenium的準確代理地址並知道進行了通信。並且他們也許檢查有chromedriver的js執行引起的修改。

3.通過具有偏移量的元素來檢測——通過selenium點擊一些帶有偏移量的元素（按鈕）仍會引發。例如從掃碼登錄切換到賬號密碼登錄的按鈕。我想阿里對於自然用戶行為肯定有一番研究的。

-----------------------------------------------------------------------------------------------

ok，通過低效的最笨的方法，按鍵精靈思想，來模擬：

我來寫一個shell腳本，通過像素點坐標，從驅動層模擬鍵盤滑鼠的操作，繞過檢測。

成功了！

但是此方法效率低，並且限制也比較多，例如屏幕大小和解析度不可隨意變更，不支持headless。

shell的代碼就不公佈（因為我不知道您的使用意圖）。很簡單，但思想必須到位。

ps：留言評論我都會認真看的，另外有更好的想法可通過[email protected]與我取得聯繫方式交流。

推薦閱讀：

相關文章