Виявлення headless-браузерів: Playwright, Puppeteer та інші

Headless-браузери — зброя вибору для витонченого веб-скрапінгу, credential stuffing та шахрайства. На відміну від простих HTTP-клієнтів, headless-браузери виконують JavaScript, рендерять сторінки й підтримують сучасні веб-API — тож їх значно важче виявити. Наш рушій Bot Detection застосовує кілька незалежних методів, щоб розпізнавати 15+ фреймворків автоматизації з майже нульовою часткою хибних спрацювань.

Еволюція автоматизації браузерів

Автоматизація браузерів пройшла довгий шлях від простих curl-скриптів. Сучасні інструменти на кшталт Playwright, Puppeteer та Selenium WebDriver керують справжніми браузерними рушіями — Chromium, Firefox чи WebKit — у headless-режимі. Вони виконують JavaScript, обробляють CSS, рендерять елементи canvas і обслуговують WebGL-запити так само, як і звичайні браузери з інтерфейсом. Це робить їх невидимими для методів виявлення, які просто перевіряють здатність виконувати JavaScript.

Найновіше покоління інструментів пішло ще далі. Stealth-режим Playwright патчить багато сигналів, на які покладається традиційне виявлення ботів. Puppeteer-extra-plugin-stealth змінює властивості navigator, перевизначає рядки vendor у WebGL і підробляє події взаємодії користувача. Ці заходи проти виявлення породили гонку озброєнь між операторами ботів і системами виявлення.

Метод виявлення 1: аналіз прапорця WebDriver

Властивість navigator.webdriver отримує значення true, коли браузером керує автоматизація. Раннє виявлення зводилося до простої перевірки цієї властивості. Але сучасні stealth-інструменти видаляють або перевизначають її. Наше виявлення сягає глибше — ми перевіряємо не лише значення властивості, а й її дескриптор, її присутність у ланцюжку прототипів і те, чи були спроби її перевизначити. Ми також перевіряємо пов'язані властивості, як-от аномалії довжини navigator.plugins, що супроводжують перевизначення WebDriver.

Метод виявлення 2: артефакти Chrome DevTools Protocol

Playwright і Puppeteer керують браузерами через Chrome DevTools Protocol (CDP). Навіть коли stealth-режим активний, CDP залишає артефакти в середовищі виконання: специфічні глобальні змінні, змінені функції-getter і модифіковані дескриптори властивостей об'єктів Window та Navigator. Ми зондуємо ці артефакти методами, стійкими до простого перезапису.

Метод виявлення 3: fingerprinting headless-браузерів

Headless Chrome має інший набір можливостей, ніж Chrome з інтерфейсом. Йому бракує певних браузерних плагінів, він має інші характеристики рендерингу для деяких CSS-властивостей і повертає інші значення для деяких результатів MediaQuery. Ми підтримуємо базу даних відомих характеристик headless-браузерів і звіряємо з нею вхідні fingerprint'и.

Ключові індикатори headless включають: відсутність chrome.runtime (присутній у Chrome з інтерфейсом, але відсутній у headless), масив navigator.plugins нульової довжини, специфічні патерни user agent, що асоціювалися з headless-режимом у попередніх версіях, і відмінності в тому, як headless Chrome обробляє контексти безпеки iframe.

Метод виявлення 4: аналіз довжини eval

Різні рушії JavaScript мають різні реалізації вбудованих функцій, і ці реалізації мають різні рядкові представлення. Перевіряючи довжину Function.prototype.toString.call(eval) і порівнюючи її з відомими значеннями для кожного браузерного рушія, ми можемо виявити підміну середовища — наприклад, екземпляр headless Chrome, що видає себе за Firefox.

Метод виявлення 5: перехресна валідація TLS

Як обговорювалося в нашій статті про TLS fingerprinting, повідомлення TLS Client Hello викриває фактичний браузер чи HTTP-бібліотеку, що встановлює з'єднання. Коли Playwright-скрипт керує Chrome, TLS-fingerprint збігається з Chrome — це очікувано. Але коли кастомний бот використовує бібліотеку requests на Python чи net/http на Go, TLS-fingerprint викриває обман незалежно від того, який рядок user agent надіслано.

Метод виявлення 6: аналіз таймінгу та поведінки

Реальні користувачі демонструють природну варіативність таймінгу взаємодій. Вони рухають мишею по кривих, а не прямих лініях, роблять паузу перед кліком, прокручують зі змінною швидкістю. Автоматизовані інструменти, навіть ті, що симулюють людську поведінку, породжують статистично відрізнювані патерни — надто рівномірний таймінг, ідеально лінійні траєкторії миші й неприродні швидкості прокручування.

Ми збираємо мінімальні поведінкові сигнали під час самого процесу fingerprinting'у — таймінг викликів API, порядок збору сигналів і реактивність певних браузерних API. Ці мікроповедінкові сигнали важко підробити інструментам автоматизації, бо вони залежать від фактичного середовища виконання, а не від властивостей, які можна перевизначити.

Метод виявлення 7: неузгодженість дозволів та API

Реальні браузери мають узгоджені стани дозволів і доступність API. Браузер, який заявляє про підтримку сповіщень, але не має конструктора Notification, або який повідомляє певну роздільну здатність екрана, але повертає інші значення з window.screen і CSS media queries, демонструє неузгодженості, що вказують на втручання чи емуляцію.

Ми перевіряємо десятки таких точок перехресної валідації, шукаючи суперечності, які виникають, коли інструменти автоматизації вибірково перевизначають деякі сигнали, не зберігаючи узгодженості між усіма пов'язаними API.

Метод виявлення 8: виявлення VM та емуляції

Багато ботових операцій працюють усередині віртуальних машин чи хмарних інстансів. Хоча саме по собі це не є доказом автоматизації, це сильний сигнал у поєднанні з іншими індикаторами. Ми виявляємо VM за рядками рендерера WebGL, що містять пов'язані з VM ключові слова (як-от "llvmpipe" чи "SwiftShader"), за апаратними характеристиками, несумісними зі споживчими пристроями (рівно 2 ядра CPU і 2 ГБ пам'яті — типові дефолти VM), і за відомими діапазонами IP хмарних провайдерів.

Перевага мультиметодного підходу

Кожен метод виявлення окремо має обмеження — витончений оператор ботів може обійти будь-який окремий метод. Але обійти всі методи одночасно, зберігаючи узгодженість перехресної валідації між усіма ними, надмірно дорого. Вартість розробки та підтримки бота, що проходить усі перевірки, перевищує економічну цінність більшості ботових операцій.

Майже нульова частка хибних спрацювань

Наше виявлення працює за whitelist-моделлю для ботів пошукових систем (Googlebot, Bingbot тощо), верифікованих через reverse DNS, і за мультисигнальною моделлю для решти трафіку. Ми вимагаємо кількох підтверджувальних сигналів, перш ніж класифікувати трафік як автоматизований. Цей консервативний підхід забезпечує частку хибних спрацювань нижче 0,1% — верифіковано на мільярдах продакшн-подій.