Метод идентификации через определение дополнений, установленных в Chrome и Firefox
Первый метод затрагивает все браузеры с поддержкой API WebExtensions (Chrome, Opera, Yandex Browser, Edge, Vivaldi) и основывается на получении информации по сторонним каналам (side-channel attack), а именно учёте различия времени обработки операций, при обработке файлов определённых дополнений. Правила доступа к файлам дополнения задаётся в файле manifest.json и приводят к небольшим, но уловимым, задержкам при попытке обращения к подпадающим под эти правила ресурсам.
В частности, время отзыва при попытке доступа к локальным файлам несуществующего дополнения немного дольше, чем при обращении к файлам установленного дополнения, при использовании изначально фиктивных файловых путей. Иными словами, время доступа к связкам "chrome-extension://[fakeExtID]/[fakePath]" и "chrome-extension://[realExtID]/[fakePath]" отличается, что позволяет методом перебора известных идентификаторов дополнений определить установленные в браузере дополнения. Если дополнение не установлено, время выполнения запроса будет совпадать, а если проверяемое дополнение присутствует - запрос будет выполнен быстрее.
Примечательно, что данной проблеме подвержен и старый API для построения дополнений к Firefox, на смену которому идёт WebExtensions. В случае старого API не требуется даже измерять время ответа, так как при запросе несуществующего файла в установленном и фиктивном дополнении выдаётся разный код ошибки. Новая система дополнений Firefox на базе WebExtensions не подвержена данной проблеме, так как в отличие от Chrome идентификаторы дополнений генерируются случайно.
При этом в ходе анализа выявлена другая проблема - случайный идентификатор дополнения Firefox сохраняется для всех версий дополнения в текущей системе и если дополнение допускает его утечку, то данный идентификатор дополнения можно рассматривать как уникальный идентификатор пользователя. Вероятно, данная проблема более опасна, чем изначально предложенный метод построения списка дополнений, так как в ходе проверки гипотезы удалось получить данные о случайном идентификаторе предустановленного дополнения Screenshot при нажатии кнопки создания снимка экрана на стороннем сайте. Для других популярных дополнений возможно будет определён метод, работающий без необходимости совершения пользователем определённых действий.
Второй метод получения списка дополнений специфичен для системы дополнений браузера Safari, в которой вместо manifest.json для разграничения доступа применяется случайно сгенерированные URL, привязываемые к текущему пользовательскому сеансу. Суть метода в том, что можно определить косвенные данные, которые используются при генерации случайного URL, и попытаться предсказать его. Проверка показала, что подобное удаётся для 40.5% протестированных дополнений.
Источник: http://www.opennet.ru/opennews/art.shtml?num=47103
|
0 | Tweet | Нравится |
|