Браузери, запущені через Selenium, можуть відрізнятися портами налагодження, властивостями, доступними сторінці, та способом запуску. Частину параметрів можна узгоджувати розумно, тоді як спроби приховати сам факт автоматизації крихкі, непотрібні й часто швидко втрачають ефективність.
Під час автоматизації через Selenium буває, що логіка скрипту правильна, а потрібного результату все одно немає. Першою реакцією часто стає зміна одного-двох параметрів, але середовище зазвичай видає не один перемикач, а поєднання відмінностей на кількох рівнях. Якщо розглядати ці рівні окремо, легше зрозуміти, що справді варто налаштовувати, а що майже не дасть користі.
Порти налагодження та артефакти середовища виконання
Спосіб, яким Selenium керує браузером, залишає два типи слідів. По-перше, під час запуску браузер може відкрити порт налагодження, через який зовнішнє програмне забезпечення може перебрати керування сторінкою. По-друге, у середовищі виконання можуть з’явитися додаткові елементи: глобальні змінні з префіксом cdc_, які додає драйвер, додаткові об’єкти драйвера у window та змінені частини деяких прототипів об’єктів.
Джерело цих елементів — не вебсторінка, а сам драйвер. За стандартного запуску вони присутні незалежно від того, наскільки добре написано скрипт.
Властивості, які може прочитати сторінка
Інший тип слідів міститься не в драйвері, а в JavaScript-середовищі, доступному сторінці. Найчастіше згадують navigator.webdriver.
Ця властивість може мати три значення. true означає, що браузер керується інструментом автоматизації, false — що такого керування немає, а undefined — що відповідна інформація недоступна, зазвичай через те, що браузер не показує цю властивість або її було оброблено. Під час звичайного використання людиною значення зазвичай false або undefined, а за стандартного запуску Selenium — true.
Поруч існує ширший набір параметрів: User-Agent, операційна система й версія браузера, роздільна здатність екрана, часовий пояс, мова, Canvas, WebGL, AudioContext, список шрифтів, модель GPU та кількість ядер CPU. Разом вони формують те, що зазвичай називають відбитком браузера. У реальних користувачів відбитки природно різняться через відмінності систем, програм і звичок. Браузери з типовими параметрами автоматизації, навпаки, можуть створювати дуже схожі комбінації, через що їх легше віднести до відомих шаблонів.
Відмінності через спосіб запуску та час рендерингу
Третя категорія не прив’язана до однієї властивості, а виникає через загальний спосіб запуску й рендерингу браузера.
Запуск із прапорцями автоматизації, робота в режимі headless, невідповідність розміру вікна параметрам екрана, неприродне поєднання рендерингу шрифтів і графічного драйвера або надто рівномірний час від завантаження сторінки до готовності до взаємодії самі по собі не є доказами. Разом вони можуть створити середовище, яке мало схоже на пристрій реального користувача.
Headless — типовий приклад. У нових версіях Chrome режим headless значно ближчий до звичайного браузера, ніж кілька років тому, але все одно може легше проявляти ознаки автоматизації, ніж стандартний режим, особливо на сайтах із суворим контролем ризиків.
Що можна налаштовувати розумно
Часовий пояс, мова, роздільна здатність екрана та список шрифтів не є унікальними для автоматизації. Реальні пристрої також природно різняться. Головне — внутрішня узгодженість: часовий пояс має відповідати регіону мережевого виходу, мова — типовому регіону використання, а роздільна здатність не повинна суперечити апаратному профілю.
Інакше кажучи, мета не в тому, щоб зробити середовище особливим, а в тому, щоб воно було логічним усередині. Якщо пристрій виглядає так, ніби підключається з Німеччини, але браузер повідомляє часовий пояс західного узбережжя США, системна мова лише англійська, а роздільна здатність схожа на типову для віртуального дисплея, така комбінація вже достатньо помітна.
Тому параметри середовища краще зберігати в постійному профілі. Змінити сьогодні часовий пояс, а завтра забути про мову — означає створити більше суперечностей, ніж якби нічого не змінювали.
Що намагається приховати саму автоматизацію і чому це не варто робити
Є інший клас підходів, спрямованих безпосередньо на сліди: видалити navigator.webdriver, очистити змінні, додані драйвером, приховати об’єкти драйвера або іншим способом не дати системі перевірки прочитати стан автоматизації.
Проблема в тому, що такі методи змінюють поверхню, а не основу. Системи виявлення давно не обмежуються однією властивістю; читання атрибутів — лише найповерховіший шар. Оновлення драйвера, зміна порядку виконання скрипту перевірки або система, що обходить JavaScript і безпосередньо аналізує низькорівневі результати рендерингу та комбінації характеристик пристрою, може зробити попередні зміни неефективними. Витрати на підтримку залишаються значними, а користь продовжує зменшуватися.
Крім того, на практиці такі дії часто потрапляють саме в ту сферу, яку умови використання платформ визначають як обхід технічних засобів захисту. Охайний код не змінює характеру дії лише тому, що було змінено кілька властивостей.
Мережевий рівень не можна виправити в скрипті
Навіть якщо браузерне середовище виглядає узгодженим, мережевий рівень усе одно може ідентифікувати сесію. Може враховуватися, чи належить IP дата-центру, хмарному серверу або проксі-мережі; історична репутація діапазону IP та його ASN; геолокація; щільність запитів з однієї IP-адреси; а також доступ із цієї адреси до кількох облікових записів чи сторінок за короткий час. Cookies, Sessions і стан входу, передані в запитах, також можуть зіставлятися.
Це не вирішується всередині скрипту — питання потрібно обробляти на рівні середовища: окремий мережевий вихід для кожного завдання, відповідність регіону виходу регіону середовища та контрольований темп запитів. Під час ізоляції кількох завдань можливості на кшталт PurpleMark зазвичай працюють саме на цьому рівні, надаючи кожному завданню незалежне браузерне середовище та мережевий вихід із узгодженими географічними параметрами.
Практичний порядок перевірки після блокування
Розумний порядок такий: спочатку перевірити мережевий рівень — тип IP, стабільність і географічну узгодженість; потім переконатися, що в середовищі не суперечать один одному часовий пояс, мова, роздільна здатність і шрифти; далі подивитися на ритм поведінки, наприклад постійні значення очікування або миттєве введення; і лише наприкінці перейти до властивостей автоматизації на рівні драйвера.
Причина проста: артефакти драйвера вже не є головним об’єктом виявлення. Якщо починати діагностику з них, найчастіше це лише втрата часу.
Межі
Технічні заходи можуть зменшити ймовірність ідентифікації, але є межі, які не слід переходити: дотримуйтеся правил robots і умов використання цільового сайту, не збирайте персональну інформацію, не обходьте технічні засоби захисту, контролюйте частоту запитів і не заважайте нормальній роботі чужого сервісу.
