Обнаружение 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, подменяет строки вендора WebGL и подделывает события пользовательского взаимодействия. Эти меры противодействия обнаружению породили гонку вооружений между операторами ботов и системами обнаружения.

Метод обнаружения 1: анализ флага WebDriver

Свойство navigator.webdriver устанавливается в true, когда браузером управляет автоматизация. На раннем этапе обнаружение сводилось к простой проверке этого свойства. Но современные stealth-инструменты удаляют или подменяют его. Наше обнаружение идёт глубже — мы проверяем не только значение свойства, но и его дескриптор, его наличие в цепочке прототипов и то, предпринимались ли попытки его переопределить. Мы также проверяем связанные свойства, например аномалии длины navigator.plugins, которые сопровождают подмену WebDriver.

Метод обнаружения 2: артефакты Chrome DevTools Protocol

Playwright и Puppeteer управляют браузерами через Chrome DevTools Protocol (CDP). Даже когда включён stealth-режим, CDP оставляет артефакты в runtime: специфические глобальные переменные, изменённые функции-геттеры и модифицированные дескрипторы свойств у объектов Window и Navigator. Мы зондируем эти артефакты методами, устойчивыми к простой перезаписи.

Метод обнаружения 3: фингерпринтинг headless-браузера

Headless Chrome обладает иным набором возможностей, чем Chrome с интерфейсом. В нём отсутствуют некоторые браузерные плагины, отличаются характеристики рендеринга ряда CSS-свойств и возвращаются другие значения для некоторых результатов MediaQuery. Мы поддерживаем базу известных характеристик headless-браузеров и сверяем входящие фингерпринты с ней.

Ключевые индикаторы 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-фингерпринтинге, сообщение TLS Client Hello раскрывает, какой именно браузер или HTTP-библиотека устанавливает соединение. Когда скрипт Playwright управляет Chrome, TLS-фингерпринт совпадает с Chrome — это ожидаемо. Но когда самописный бот использует библиотеку requests на Python или net/http на Go, TLS-фингерпринт выдаёт обман независимо от того, какая строка user agent отправлена.

Метод обнаружения 6: анализ таймингов и поведения

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

Мы собираем минимальные поведенческие сигналы прямо в процессе фингерпринтинга — тайминги вызовов 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% — проверено на миллиардах реальных событий.