Google是如何處理機器風險的？

前言

在前兩篇文章中，我們已經分析過了多種應對機器風險的方案，其中比較廣為人知且行之有效的就是驗證碼了。上文中也提到，傳統的圖形驗證碼對抗已經進入了安全和用戶體驗難兩全的惡性循環，而基於用戶行為的無答案性防禦方式正在興起，以Google的recaptcha為代表，將傳統的考驗機器回答問題能力，改為考驗機器是否具備正常用戶行為能力，似乎是目前較為行之有效的方案。

recaptcha 是什麼

Protect your website from spam and abuse while letting real people pass through with ease

這是recapthca官網的原文，從目標上似乎和各式各樣的驗證碼並沒什麼什麼區別。不過在 real people 的體驗上卻要好很多。其推崇的是隱形的驗證碼，用戶只需要在指定位置點一下滑鼠，即可通過驗證。

recaptcha 運行原理

recapthca的實現原理其實說起來很簡單，大致為：

• 通過前端腳本收集用戶行為信息。
• 上傳用戶行為信息。
• 通過用戶的歷史行為以及當次用戶行為進行判斷，是否為機器。

沒錯，原理就是這麼簡單，似乎簡單地可怕。然而現實和理想直接永遠有巨大的差距，如果黑客們有這麼好對付，也不需要Google工程師們這麼長時間的對抗了。一個稍微有攻擊經驗的人都會提出以下疑問：

• 前端腳本是明文載入的，所有的採集邏輯都暴露在外，只需要自己拼湊一份採集數據模擬正常用戶行為即可。
• 大量的js執行環境存在，比如phantom、webdriver等等，還有按鍵精靈之類的存在，我只需要模擬動動滑鼠，一切就可以搞定。
• 想要瀏覽器存住歷史行為並不容易（我們已經在之前的文章分析過），黑客們才不會傻到讓你有一系列的行為可以分析。
• 正常用戶行為各異，如何保證不誤傷。只要你不敢保證百分百攔截疑似行為，黑客們就會混跡於這些疑似行為之中。

我們看下recapthca是如何應對上述問題的：

recapthca 實現

載入

recapthca並不像傳統的ui組件顯示在頁面之上，它是一個獨立的iframe，作為一個獨立的頁面引入你的應用，這樣設計，很明顯是為了進行頻繁的更新。

毫無疑問，黑客們面對的將是一個頻繁更新的匣子。

前端加密

我們簡單看下recapthca頁面載入了哪些js，首先會載入一個名為

https://www.gstatic.com/recaptcha/api2/r20161215161951/recaptcha__zh_cn.js

的js文件，其主要功能是一些通用代碼，以及UI層面的代碼，js本身並未進行高度混淆，可以理解為驗證碼本身的業務代碼主要彙集於此。

於此，html內部會內嵌兩段 script 標籤

第一段script標籤：

我經過分析之後，發現此段script標籤的大致行為是：

遍歷所有的html原生標籤，分別在頁面中的某個隱藏部位插入，然後遍歷這些原生標籤的屬性，收集起來。對此，目的應該很明顯，就是為了深度檢測當前執行環境是否為一個真實的瀏覽器。恐怕應該沒有人比chrome的工程師自己知道應該存在哪些屬性吧，哈哈。

第二段內嵌腳本：

第二段腳本從命名來看顯然是一個主邏輯入口，然而其參數是經過加密再base64之後的結果，看起來甚為壯觀！我曾經嘗試解開這一大段字元串的原文，發現其為base64加密的二進位流，顯然這種設計，說明這段字元串為某些會動態變化的下髮指令藏身處，我繼續跟進方法，該方法指向了另一個最為關鍵的js腳本：

https://www.google.com/js/bg/u09rP0-0WJXXTCfMa3Rfue5UdOXh3MbmZv49j_FU3OI.js

從js名字就能看出來，這個js應該是經過保護的，即使做好了心理準備，結果還是超過我想像 - -。

首先是一段富有情懷的注釋233：

/* Anti-spam. Want to say hello? Contact (base64) Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29t */ n

看來Google似乎想在這一步告訴你，如果你夠geek，應該主動聯繫他們，說不定能給你提供個職位啥的，而不是在這裡搞破壞。

接著就是一大段eval函數：

實不相瞞，在多次嘗試之後，我實在只能對此腳本略有了解，腳本本身是經過高度混淆加密的，不僅所有的變數名都變成不可讀，甚至連對象的屬性名都進行了混淆，而且是還將變數分布在不同的對象深度中，大部分的屬性或方法調用能看到的不過是：a.b.c.d()。從我的視角能看到的是這段js中實現了一個自定義的完整的二進位轉指令的演算法，但是我還不能完全理解這個演算法。

有一個外國友人提到：

It turned out this new ReCaptcha system is heavily obfuscated, as Google implemented a whole VM in JavaScript with a specific bytecode language.

即Google用js實現了一個完整的 虛擬機， 後台動態輸出不同的指令，讓邏輯隱藏在自己設計的指令之中。不管是不是虛擬機，總之，對於該腳本傳輸的密文似乎並不能輕易的破解，也就是說，你可能無法直接偽造一份採集數據的密文發送給Google的伺服器。

採集數據

除了上面提到過了的瀏覽器標籤屬性，recapthca大概還採了下面的這些內容：

• 插件列表
• useragent
• 瀏覽器解析度
• 執行時間
• click、touch、keyboard事件
• canvas帆布指紋
• cookie

等等，這些特性除了能夠檢測你的當前執行環境以外，還可以一定程度上將你的上次行為找出來，也就是傳說中的「設備指紋」。將瀏覽器可採集到的數據做歷史分析，你的下一次數據和其中一份數據分毫不差的對應上了，就可以把你的歷史行徑全部找出來，從而輔助分析你是否為一個「老實」的用戶。

模型

對於真實用戶行為的模型建立並不是一件特別容易的事情，不過對於以演算法著稱的Google來說，或許沒那麼困難，由於這部分完全屬於黑盒了，暫時無法對其背後的模型進行分析。

兜底方案

上面還有的疑問，Google如何保證不誤傷用戶？我們可以用隱身模式打開Google的recapthca頁面，然後極快的點擊人機驗證區域，發現了如下反應：

在他們無法很好的分析出你是否為正常用戶的時候，會回退到圖形驗證碼步驟，不過並不是基本的圖形驗證碼，而是分類驗證碼，不過其圖片清晰程度和問題對比國內的某些分類驗證碼，體驗也好了一個檔次。

總結

• recapthca 通過前端加密來保證數據傳輸的安全性，不會被直接偽造臟數據
• recapthca 通過分析瀏覽器特徵，判斷是否為phantom等非真實瀏覽器環境
• recapthca 通過行為模型，分析採集的數據是否具有機器風險
• recapthca 對應有機器風險的用戶，會出圖形分類驗證碼進行二次驗證，而沒有風險的用戶，會直接通過
• recapthca 的用戶體驗遠遠高於普通的驗證碼
• recapthca 的安全性可能會高於傳統的驗證碼方案

推薦閱讀：