大多數 IT 安全專(zhuān)業(yè)人員現在都非常清楚惡意機器人以及它們對任何在線(xiàn)業(yè)務(wù)所構成的持續威脅。因此，對反機器人軟件的需求正在迅速增加。高效的機器人程序保護解決方案必須能夠準確地區分不良機器人程序、良好機器人程序和人類(lèi)，最好是實(shí)時(shí)進(jìn)行。為了確定訪(fǎng)問(wèn)者是人還是機器人，我們可以從服務(wù)器端和客戶(hù)端、瀏覽器或移動(dòng)應用程序中收集信息。

在下文中，我們將演示為什么完全依賴(lài)服務(wù)器端檢測的解決方案對某些類(lèi)型的機器人無(wú)能為力，以及為什么必須由客戶(hù)端信號完成分析才能真正有效地保護機器人。

服務(wù)器端指紋識別基本機器人

服務(wù)器端檢測通?；谝韵滦畔ⅲ?/p>

HTTP指紋：由瀏覽器發(fā)送的HTTP頭組成的指紋，例如用戶(hù)代理或支持的壓縮算法。

TCP 指紋：TCP 指紋利用 TCP 堆棧中的差異（例如數據包的順序）來(lái)確定發(fā)送請求的瀏覽器或設備的性質(zhì)。

TLS 指紋：這些指紋使用一組受支持的TLS 密碼套件來(lái)識別發(fā)出請求的設備和軟件（例如移動(dòng)應用程序）的性質(zhì)。

服務(wù)器端行為特征：請求的數量、頻率、是否存在瀏覽模式，可以用來(lái)判斷用戶(hù)是否為人。

這種服務(wù)器端檢測是必要的主要措施，但還不夠。

服務(wù)器端機器人檢測的局限性是什么？

面對最新一代的機器人程序，僅具有服務(wù)器端檢測功能的安全解決方案很快就會(huì )遇到其局限性。這是因為這些高級機器人使用與人類(lèi)用戶(hù)完全相同的瀏覽器——Chrome、Firefox、Safari——或像 Headless Chrome 這樣的無(wú)頭瀏覽器。

與不能執行 JavaScript 的基本機器人不同，這些高級機器人具有一致的 HTTP、TCP 和 TLS 指紋。

此外，無(wú)論何時(shí)存在小的不一致，例如非人類(lèi)用戶(hù)代理，都可以通過(guò)向機器人添加幾行代碼或使用開(kāi)源檢測框架來(lái)偽造一致的指紋來(lái)輕松修復（我們將對此進(jìn)行更詳細的討論以下）。

如果您只做服務(wù)器端檢測，那么您對這些機器人程序完全視而不見(jiàn)。您唯一的機會(huì )是依靠服務(wù)器端的行為特征，并等待機器人觸發(fā)您的請求量閾值，然后您才能阻止它們。

這種方法總是會(huì )錯過(guò)使用代理頻繁更改其 IP 地址的機器人。即使他們不這樣做，在您識別并阻止它們時(shí)，針對客戶(hù)關(guān)鍵接觸點(diǎn)（例如您的登錄頁(yè)面）的機器人可能已經(jīng)造成了很多傷害。這就是為什么真正有效的機器人檢測解決方案必須將服務(wù)器端檢測與客戶(hù)端檢測相結合的原因。

客戶(hù)端機器人檢測功能：

客戶(hù)端（瀏覽器內）跟蹤可以記錄和分析有關(guān)用戶(hù)設備和瀏覽器發(fā)出請求的各種低級事實(shí)，以及行為信號。

例如：

瀏覽器跟蹤：功能存在、js 挑戰……

應用跟蹤：相機版本、屏幕分辨率、觸摸點(diǎn)數量……

設備跟蹤：CPU 內核數、設備內存、GPU……

用戶(hù)事件跟蹤：鼠標移動(dòng)和觸摸事件……

這些客戶(hù)端信號對于檢測最先進(jìn)的機器人程序至關(guān)重要，即使它們偽造指紋以繞過(guò)不太復雜的安全系統也是如此。但是不要相信我們的話(huà)：讓我們通過(guò)放大一個(gè)特定的用例和一種客戶(hù)端檢測方法，向您展示當您不收集任何客戶(hù)端信號時(shí)會(huì )發(fā)生什么。

用例：修改指紋以避免檢測的高級無(wú)頭 Chrome 機器人。

在此用例中，惡意行為者試圖使用數千個(gè)基于 Headless Chrome 和Puppeteer 的機器人進(jìn)行撞庫攻擊。

默認情況下，Headless Chrome 可以通過(guò)其用戶(hù)代理在服務(wù)器端被識別：

Mozilla/5.0 (X11; Linux x86_64)

AppleWebKit/537.36 (KHTML, like Gecko)

HeadlessChrome/79.0.3945.88

Safari/537.36

但是，流行的開(kāi)源庫（例如Puppeteer extra）使開(kāi)發(fā)人員能夠擦除這些明顯的檢測信號。

Puppeteer extra 庫為 Puppeteer 檢測框架添加了更多功能。得益于其隱身插件，黑客可以輕松修改其 Headless Chrome 機器人的指紋。僅此一項就足以繞過(guò)大多數現有的機器人檢測系統。

默認情況下，Puppeteer extra 將更改機器人的用戶(hù)代理，以便它們與人類(lèi)訪(fǎng)問(wèn)者保持一致，并刪除傳統上用于檢測 Headless Chrome 的屬性，例如navigator.webdriver 。

該庫還使機器人開(kāi)發(fā)人員能夠偽造其他幾個(gè)屬性，例如插件列表、可用編解碼器或 GPU。

如果您想自己嘗試，可以使用以下代碼輕松啟動(dòng)基于 Puppeteer 隱身的爬蟲(chóng)。與傳統的 Puppeteer 程序相比，主要區別在于您不導入puppeteer，而是導入 puppeteer-extra：

const puppeteer = require('puppeteer-extra')

// 啟用帶有所有規避的隱身插件

puppeteer.use(require('puppeteer-extra-plugin-stealth')());

(async () => {

// 以無(wú)頭模式啟動(dòng)瀏覽器并設置頁(yè)面。const

browser = await puppeteer.launch({

headless: true

})

const page = await browser.newPage()

// 導航到將執行測試的頁(yè)面。

const url = “https://你的網(wǎng)站……”；

等待 page.goto(url)

等待 browser.close()

})()

如果您現在驗證機器人的用戶(hù)代理，您可以看到它已成為合法用戶(hù)代理：

const userAgent = await page.evaluate(() => {

return navigator.userAgent;

})

console.log(userAgent)

// Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome /80.0.3987.0 野生動(dòng)物園/537.36

Headless Chrome 有一個(gè)等于 true 的navigator.webdriver屬性。當我們在 Puppeteer stealth 中驗證這個(gè)值時(shí)，我們可以看到navigator.webdriver不再出現在 bot 的指紋中，這使得這種技術(shù)無(wú)法檢測到它。

const webdriver = await page.evaluate(() => {

return navigator.webdriver;

})

console.log(webdriver)

// undefined

由于用戶(hù)代理和 HTTP 標頭都與人類(lèi)用戶(hù)相同，因此簡(jiǎn)單的服務(wù)器端 HTTP 指紋識別不足以將此訪(fǎng)問(wèn)者識別為機器人。如果您的 bot 保護解決方案完全依賴(lài)服務(wù)器端檢測，您唯一的希望是它遲早會(huì )顯示可疑行為。

另一方面，由于先進(jìn)的客戶(hù)端檢測，像 DataDome 這樣的解決方案可以在他們第一次請求時(shí)識別這些高級機器人，即使它們是故意設計來(lái)避免檢測的。

例如，Puppeteer stealth 用來(lái)繞過(guò)檢測的技術(shù)之一是覆蓋 canPlayType函數，該函數用于測試音頻和視頻編解碼器的存在。

但是，這樣做會(huì )留下痕跡。實(shí)際上，我們可以通過(guò)執行以下代碼來(lái)測試 canPlayType 函數是否已被覆蓋。

在Puppeteer stealth plugin 2.4.5版本中，運行如下代碼，可獲得：

const canPlayTypeTs = await page.evaluate(() => {

var audioElt = document.createElement(“audio”);

return audioElt.canPlayType.toString();

})

console.log(canPlayTypeTs)

// 'function () { [本機代碼] }'

但是，對于人類(lèi)使用的合法 Chrome 瀏覽器，您獲得了：

'函數 canPlayType() { [本地代碼] }'

結論：第一個(gè)用戶(hù)是一個(gè)機器人。