Експериментальні методи виявлення браузерів із підміною відбитка: від заявленої версії до перевірки поведінки

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

Дослідження Browser Polygraph, опубліковане на ACM Internet Measurement Conference (IMC) 2024, виконали дослідники з Arizona State University, Boston University і Amazon; DOI роботи — 10.1145/3646547.3688455. Замість симульованих лабораторних даних систему на 4,5 місяця розгорнули в реальному виробничому середовищі великої фінансової компанії. Спостереження охопило 205 000 справжніх користувацьких сесій. Було протестовано десять поширених рішень для маскування середовища, а звичайний користувацький трафік використовувався як контрольна група.

Як було побудовано експеримент

Три проєктні рішення дали змогу застосовувати виявлення до всього трафіку без впливу на бізнес-процеси.

Ознаки мали бути дешевими для збирання. Детектор зчитує лише фіксований набір властивостей, а накладні витрати одного запуску вимірюються мілісекундами та KB. Тому перевірку можна виконувати для всього трафіку без вибірки й без помітного ефекту для користувача.

Ознаки мали бути стабільними. Дослідники обрали не параметри, які користувач може змінити, а внутрішні структури, що задаються самим браузером. Кожна версія браузера має свій JavaScript-рушій, а між версіями є невеликі відмінності в кількості API та властивостей окремих об’єктів. У дослідженні для порівняння використовувався діапазон Chrome 110–Chrome 114: система підраховувала властивості 28 ключових об’єктів і зіставляла результат із версією, яку заявляв браузер. Якщо вони не збігаються, декларація та фактична поведінка походять не з однієї технічної основи.

Мітки мали бути надійними. Кожне тестоване середовище по черзі підключали до того самого виробничого трафіку й оцінювали за однаковими правилами, а контрольна група складалася з нормальної поведінки реальних користувачів. Отже, результат показує не суб’єктивне «наскільки це схоже на справжнє», а те, чи можна відрізнити такий трафік за єдиними правилами.

Показники для оцінки реалістичності симуляції

Використані в дослідженні вимірювання можна поділити на чотири групи.

• Узгодженість: чи відповідає заявлена версія браузера структурі його внутрішніх об’єктів? Це ключовий і найскладніший для підробки показник, адже зміна одного рядка не змінює одночасно кількість об’єктів і властивостей у рушії.
• Частка виявлення: для чотирьох рішень дослідження провело детальні тести, у яких частка виявлення становила від 67% до 84%.
• Відхилення від реальних пристроїв: за однакових правил звичайні браузери отримували оцінку ризику 0, а тестовані рішення в середньому — від 8,85 до 11,66. Цей показник відображає відстань до реального розподілу, а не суб’єктивне враження схожості.
• Розрізнюваність: чи можна відокремити тестований трафік від звичайного? Якщо певну категорію відокремити не вдається, то за цим методом у неї немає видимого поведінкового розриву з реальними браузерами.

Із чотирьох показників перший є причиною, а решта три — її наслідками.

Де відрізняються чотири категорії результатів

Дослідження поділило протестовані рішення на чотири категорії за способом реалізації нижнього рівня.

У першій категорії низькорівневі ознаки не відповідають жодній відомій реальній версії браузера, тобто їм не відповідає жоден реальний рушій. Проста перевірка одразу виявляє невідповідність.

У другій категорії середовище має реальні ознаки відбитка, але під час зміни ідентичності змінюється лише зовнішня декларація, тоді як базовий рушій залишається тим самим. Це був найпоширеніший випадок у дослідженні. Образно кажучи, на візитівці вказана нова версія, але акцент досі старий. Проблема не в тому, наскільки добре налаштовані окремі параметри, а в розриві між декларацією та поведінкою; саме звідси походить значна частина виявлень.

У третій категорії базовий рушій змінюється разом з ідентичністю. Якщо середовище заявляє певну версію, запускається рушій, що відповідає цій версії, тому узгодженість зберігається і цей детектор не зміг відрізнити такий трафік. У статті також зазначено, що для виявлення цієї категорії потрібні складніші методи.

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

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

Практичні підказки для вибору рішення середовища

Фокус виявлення змістився від читання декларацій до перевірки поведінки, тому змінювані поверхневі параметри дають дедалі менше переваг. Під час практичної оцінки:

• Запитуйте про нижній рівень, а не про список параметрів. Коли змінюється заявлена версія, чи змінюється разом із нею базовий рівень? Чи формуються відбитки автоматично як реальні комбінації, чи вручну складаються з окремих значень?
• Порівнюйте середовища між собою. Якщо кілька середовищ повертають дуже схожі низькорівневі ознаки, ізоляція неповна.
• Спочатку узгодженість, потім відмінність. Чим більше налаштовується внутрішньо суперечливих ознак, тим більшою стає поверхня для виявлення.
• Проходження загальної сторінки перевірки не означає, що платформа прийме середовище. Остаточну перевірку все одно варто провести на невеликому обсязі реального трафіку.

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