Расширения Google Chrome позволяют снять цифровой отпечаток браузера

Расширения Google Chrome позволяют снять цифровой отпечаток браузера

Расширения Google Chrome позволяют снять цифровой отпечаток браузера

Исследователь в качестве эксперимента создал веб-сайт, использующий установленные у посетителей расширения браузера Google Chrome для снятия его цифрового отпечатка и последующей идентификации и отслеживания этого пользователя.

Цифровой отпечаток, как правило, подразумевает использование различных характеристик устройства пользователя, которые помогают веб-сервисам «узнавать» посетителя. Среди таких характеристик могут быть инсталлированные приложения, мощность GPU, разрешение экрана, аппаратная начинка и даже установленные шрифты.

На выходных веб-разработчик, известный под онлайн-псевдонимом “z0ccc“, поделился своим методом снятия цифрового отпечатка — “Extension Fingerprints“. Суть заключается в том, что создать трекинг-хеш можно с помощью установленных аддонов Google Chrome.

Известно, что при создании Chrome-расширения можно отметить определённые активы в качестве “доступных из Сети ресурсов“, к которым могут получить доступ веб-страницы и другие аддоны.

Как правило, такие ресурсы представляют собой файлы изображений, у которых указано свойство “web_accessible_resources“. Например, это может выглядеть так:

"web_accessible_resources": [
    {
      "resources": [ "logo.png" ],
      "matches": [ "https://anti-malware.ru/*" ]
    }
],

Всё это можно использовать для проверки установленных в системе пользователя расширений Google Chrome. Выделив инсталлированные аддоны, условный злоумышленник может создать цифровой отпечаток браузера посетителя.

«Фетчинг определённых защищённых расширений занимает дольше времени, чем неустановленных аддонов. Замеряя временные промежутки, вы можете вычислить, какие расширения пользователь установил», — объясняет  “z0ccc“ на GitHub-странице своего проекта.

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

Дальше выяснилось, что деинсталлятор некорректно работал с системными API: использовал неправильное соглашение о вызовах функций и неверно обрабатывал параметры стека. Из-за этого при каждой неудачной операции данные из стека удалялись неправильно.

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

RSS: Новости на портале Anti-Malware.ru