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

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

服務器端指紋識別基本機器人

服務器端檢測通常基于以下信息：

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

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

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

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

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

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

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

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

此外，無論何時存在小的不一致，例如非人類用戶代理，都可以通過向機器人添加幾行代碼或使用開源檢測框架來偽造一致的指紋來輕松修復（我們將對此進行更詳細的討論以下）。

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

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

客戶端機器人檢測功能：

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

例如：

瀏覽器跟蹤：功能存在、js 挑戰(zhàn)……

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

設備跟蹤：CPU 內(nèi)核數(shù)、設備內(nèi)存、GPU……

用戶事件跟蹤：鼠標移動和觸摸事件……

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

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

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

默認情況下，Headless Chrome 可以通過其用戶代理在服務器端被識別：

Mozilla/5.0 (X11; Linux x86_64)

AppleWebKit/537.36 (KHTML, like Gecko)

HeadlessChrome/79.0.3945.88

Safari/537.36

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

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

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

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

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

const puppeteer = require('puppeteer-extra')

// 啟用帶有所有規(guī)避的隱身插件

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

(async () => {

// 以無頭模式啟動瀏覽器并設置頁面。const

browser = await puppeteer.launch({

headless: true

})

const page = await browser.newPage()

// 導航到將執(zhí)行測試的頁面。

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

等待 page.goto(url)

等待 browser.close()

})()

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

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 野生動物園/537.36

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

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

return navigator.webdriver;

})

console.log(webdriver)

// undefined

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

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

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

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

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

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

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

return audioElt.canPlayType.toString();

})

console.log(canPlayTypeTs)

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

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

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

結論：第一個用戶是一個機器人。