Как новый безголовый Chrome и сигнал CDP влияют на обнаружение ботов
Последнее обновление Headless Chrome опасно приблизило его к достижению идеального отпечатка пальца браузера. В самом начале своего существования безголовый Chrome заметно отличался от "полноценного" Chrome и был наполнен собственными причудами и ошибками. Но теперь, когда новый безголовый Chrome и Chrome используют одну и ту же кодовую базу, отличить их друг от друга стало непростой задачей - ведь у них практически одинаковый отпечаток браузера.
- Как только злоумышленник использует
- Что такое CDP?
- Как мы можем обнаружить браузеры, автоматизированные с помощью CDP?
- Обнаружение сериализации объектов
- Создание функции
- Как обновленный Headless Chrome повлиял на бот-фреймворки для защиты от обнаружения?
- Как обнаружить новые "антидетекторные" бот-фреймворки
Как только злоумышленник использует
page.setUserAgent()
для изменения своего агента пользователя и
--disable-blink-features=AutomationControlled
чтобы избавиться от
navigator.webdriver
Но в отпечатке пальца Headless Chrome осталось очень мало несоответствий. Это все равно что пытаться найти иголку в стоге сена, но иголка выглядит точно так же, как и сено!
Эта эволюция значительно повышает планку обнаружения, и поэтому необходимо понимать и использовать новые методы, такие как обнаружение побочных эффектов протокола Chrome DevTools Protocol (CDP), чтобы опередить сложные бот-среды.
Что такое CDP?
Протокол Chrome DevTools Protocol (CDP) – это набор API-интерфейсов и инструментов, позволяющих разработчикам программно взаимодействовать с браузерами на базе Chromium. Он позволяет отлаживать, профилировать и проверять веб-приложения, предоставляя доступ к внутренним компонентам браузера. CDP также является базовым протоколом, используемым основными бот-фреймворками, такими как Puppeteer, Playwright и Selenium, для работы с браузерами на базе Chromium. Таким образом, возможность обнаружить, что браузер оснащен CDP, является ключевой для обнаружения большинства современных бот-фреймворков.
Обнаружение CDP нацелено на базовую технологию, используемую для автоматизации, а не на специфические несоответствия и побочные эффекты, добавляемые конкретным бот-фреймворком. Это обеспечивает более универсальное обнаружение отпечатков пальцев, даже для неизвестных фреймворков автоматизации - включая те, которые пытаются остаться незамеченными, предоставляя функции защиты от обнаружения.
Помимо того, что CDP позволяет обнаруживать все виды бот-фреймворков, он эффективен как для Chrome, так и для Headless Chrome.
Как мы можем обнаружить браузеры, автоматизированные с помощью CDP?
Техника обнаружения, которую мы представим ниже, использует тот факт, что автоматический браузер и фреймворк автоматизации должны сериализовать данные при взаимодействии через WebSocket.
Мы хотим создать функцию JavaScript (JS), которая позволит нам наблюдать ситуацию, когда некоторые данные сериализуются только тогда, когда браузер автоматизирован с помощью CDP. Таким образом, нам необходимо:
- 1. Провоцировать сериализацию объекта, но только при использовании CDP.
- 2. Обнаружить, что объект был сериализован.
Провоцирование сериализации объектов
Чтобы спровоцировать сериализацию объекта, мы используем функцию
Runtime.consoleAPICalled
событие, которое передает информацию, записанную в журнал с помощью одного из элементов
window.console.
Примечание: браузеры на базе Chromium отправляют события Runtime только после того, как получат команду
Runtime.enable
от клиента, что характерно для фреймворков автоматизации.
Чтобы ограничить сериализацию только ситуациями, когда используется CDP, мы используем тот факт, что Chrome буферизирует консольные сообщения, когда DevTools (CDP) не открыт.
Обнаружение сериализации объектов
Чтобы обнаружить, что объект был сериализован, мы могли бы определить JS-геттер на случайном JS-объекте и использовать для него консольный метод. Однако в этой ситуации Chrome выполняет геттер мгновенно и кэширует его результат, не дожидаясь сериализации.
Из этого правила есть одно исключение: свойство стека объекта Error. Это нестандартное свойство, а значит, браузерные движки вольны реализовывать его по своему усмотрению. V8, движок, используемый в Chrome, работает с ним следующим образом:
В отличие от Java, где трассировка стека исключения представляет собой структурированное значение, позволяющее просмотреть состояние стека, свойство stack в V8 содержит просто плоскую строку, содержащую отформатированную трассировку стека. Это сделано без какой-либо иной причины, кроме совместимости с другими браузерами. Однако это не жестко закодировано, а только поведение по умолчанию, которое может быть переопределено пользовательскими скриптами.
Для повышения эффективности трассировка стека форматируется не в момент захвата, а по требованию, при первом обращении к свойству стека.
В Chrome свойство стека ошибки может быть переопределено, что позволяет не считывать его значение до тех пор, пока оно не понадобится.
Создание функции
Теперь, когда оба условия выполнены, мы можем создать функцию JavaScript, которая обнаруживает обращение к свойству stack ошибки:
var detected = false;
var e = new Error();
Object.defineProperty(e, 'stack', {
get() {
detected = true;
}
});
console.log(e);
// сохраняем значение `detected`.
Значение для "detected" будет
true
в браузерах Chromium, к которым подключен CDP-клиент (и который отправил команду
Runtime.enable
команду), и
false
в противном случае.
Хотя эта техника обнаруживает автоматических ботов на базе Chromium, она также обнаруживает пользователей с открытым DevTools, что может создавать ложные срабатывания. Теоретически, определение того, открыт ли пользовательский интерфейс DevTools, могло бы помочь справиться с этими нестандартными ситуациями. Однако разработчики ботов заметили, что некоторые производители антибот-программ добавили правило для проверки того, открыт ли пользовательский интерфейс DevTools, поэтому они стали автоматически запускать своих ботов с параметрами
args: ['--auto-open-devtools-for-tabs'].
Как обновленный Headless Chrome повлиял на бот-фреймворки для защиты от обнаружения?
После выхода нового Headless Chrome и использования обнаружения CDP в дикой природе разработчики ботов начали искать способы обойти это обнаружение.
Тест на обнаружение CDP хорошо документирован и теперь является частью нескольких тестовых наборов для фреймворков, защищающих от обнаружения ботов, как показано в этом репозитории, где представлен набор тестов, гарантирующих, что бот на базе ChromeDriver не будет обнаружен:
Эти изменения также привели к созданию новых фреймворков для защиты ботов от обнаружения, например, ни один драйвер не был объявлен преемником необнаруженного ChromeDriver, а Selenium Driverless.
Чтобы избежать обнаружения, эти бот-фреймворки решили не полагаться на ChromeDriver и Selenium. Вместо этого они реализуют все обычные функции автоматизации с помощью низкоуровневых команд CDP, которые не задействуют
Runtime.enable.
Как обнаружить новые "антидетекторные" бот-фреймворки
Тот факт, что эти новые фреймворки направлены на устранение основных побочных эффектов CDP и несоответствий в отпечатках пальцев, не означает, что несоответствий не осталось - просто их стало сложнее обнаружить. Таким образом, продолжение исследования других сигналов отпечатков пальцев по-прежнему является ключевым для обнаружения этих фреймворков автоматизации при одном выполнении JS.
Однако это подчеркивает необходимость многоуровневого подхода и отказа от использования только одной категории сигналов (например, отпечатков пальцев JS) для обнаружения ботов и мошенников.
В дополнение к сигналам отпечатков пальцев при обнаружении следует использовать:
- Сигналы поведенческого анализа: Использование как взаимодействий на стороне клиента (движения мыши, сенсорные события), так и шаблонов просмотра на стороне сервера (последовательности запросов, график просмотра).
- Репутационные сигналы: Репутация IP-адреса и сеанса, обнаружение прокси-серверов.
- Слабые сигналы: Такие как время суток, происхождение запроса, соответствие между IP-адресом пользователя, часовым поясом и языками.