Pull to refresh

Comments 45

Что-то из примера непонятно — этот код выполняется на сервере или в браузере?


Если я правильно понял, то атака основана на том, что браузер часть favicon-ов закеширует, а часть нет при создании отпечатка. Но при повторном визите он закеширует все остальные — т.е. эта атака одноразовая?

Нет, ведь url favicon можно генерировать скриптом

Ну и что? При первой же проверке вы на все юрл-ы сходите и закешируете их и придется еще один идентификатор генерировать. Так у вас быстро закончатся
1) идентификаторы
2) место в базе

Судя по коду, там не вполне фингерпринтинг, а персистентная кука, биты которой считываются на основании того, за какими фавиконами браузер таки пошел на сервер. То есть для пользователя просто генерируется и записывается идентификатор.

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

Я всегда думал, когда глядел на окончание путей у CSS, js в виде ?random=27474838, что для браузера это каждый раз новый путь и новый файл. С favicon не проверял.

С фавиконами — то же самое. Просто у сайта может быть, например, 32 фавикона (фавикон привязан к странице, а не домену). И факт их закешированности (читай, отсутствия запроса к серверу) — это признак конкретного браузера.

Если сервер отвечает ошибкой, то браузер ошибку не кеширует, а пробует каждый раз заново. И именно этот признак используется в режиме "чтения".

Так сервер должен заранее знать ответить 200 или ошибкой на данный конкретный бит-фавиконку. Откуда сервер это знает?
Сначала мы пробуем прочитать идентификатор, если его — тогда выполняем запись. Сервер может знать о том, какой сейчас этап.
В режиме чтения сервер, грубо говоря, отвечает всегда ошибками, но при этом ещё косвенно передаёт на клиент за какими картинками по факту ходил браузер (фавикон загружен успешно из кеша). Если клиент видит, что браузер ходил за всеми картинками, то клиент понимает, что куки ещё нет и её надо проставить. В режиме записи сервер отдаёт 200 коды на 1 биты и 404 для 0 и браузер кеширует единички.
В переводе опущен важный механизм собственно как это все работает :) Но есть ссылка на оригинал.
Там есть два режима — чтения (проверка идентификатора) и записи (запись идентификатора пользователя).
Идентификатор записывается редиректом по разным урлам. Это вот /a,/b,/c из статьи. По каким-то из них сервер на запрос фавикона отдает 200-ОК, по каким-то 404 (по сгенерированному заранее ID).
Соответственно чтение — прогнать пользователя по всем урлам и узнать какие фавиконы у него загружены, но при этом отправляя 404 в ответ. Т.е. при чтении браузер фавиконы и не получит (а сервер инфу получит). Если чтение показало, что фавиконов вообще нету, значит записи не было — прогоняем режим записи.
Как-то так.
Видно что это перевод, но статья нигде не помечена как перевод, это уже норма на хабре?
Chromium 88.0.4324.150 (Official Build) (64-bit)
В режиме инкогнито не сработало.
В обычном режиме по-умолчанию работает, но перестает, если принудительно обновить по Ctrl+F5.

Очень странные результаты. Если бы вообще починили, то и трекинг сломался бы во всех режимах, а так не пойми что.
Приватное окно FF 85.0.2 (win, x64) полностью сменило ИД — по несколько раз одновременно обновлял в обоих.
В обычном режиме по-умолчанию работает, но перестает, если принудительно обновить по Ctrl+F5.

Ctrl+F5 — тоже меняет, да.

Та же версия Firefox, но трекинг не работает и в обычном режиме. На гитхабе есть информация, что как раз в 85 версии это исправили.


Firefox 85.0.2 (x64)
Windows 10 Home 1909 (build 18363.1379)

Чего только не придумают. Скоро нужно будет каждый раз перед запуском браузера создавать чистый профиль. Хотя почему скоро? Уже сейчас.
запускать чистую систему в виртуалке)
Перед входом в инет делать снэпшот, а потом по итогу работы удалять его
Да, есть такая мысль. Ещё можно скрипт прикрутить для автоматизации.

Вы скопировали чужую статью и выдаёте за свою. Ах, ну да, это называется «вольный перевод». А я называю это мусором.

Только собрался писать подобное, искал плашку перевод — не нашёл, подумал, что наверное что-то дописали своё, но когда увидел таблицу, понял, что нового не увижу, но хотелось бы узнать по теме чуточку побольше
Яндекс браузер
обычный режим а потом инкогнито выдал одинаковые идентификаторы
UFO just landed and posted this here
UFO just landed and posted this here
Именно, что изначально был — пример. То что я привёл — это будет практика. Никто не запретит трекающим компаниям так делать.
Так, rel="icon" и говорит, что там указан favicon. Иногда пишут и так: rel="shortcut icon".

А в рекламных ссылках разве фигурирует какой-нибудь rel="ads"? Вот точно также и будет перехватывать.

Т.е. по базе доменов, IP-адресов и имён файлов. Никакой настройки на перехват именно фавиконов, в этом случае, — нет.

Что-то я не пойму, в чем уязвимость?
Ну, допустим, используя эту "уязвимость" сайт А знает, что на него заходят с конкретного ПК не единожды… и что с того?
Сайт Б ведь никогда не узнает, что я был на сайте А. Подозреваю, что такое возможно только если оба сайта будут использовать один и тот же favicon, который лежит на другом домене, либо на домене одного из сайтов? Но такой сценарий крайне маловероятен, кто может этим воспользоваться и с какой целью?

«кто может этим воспользоваться и с какой целью?» — например имеется трекинговая компания Z предоставляющая услуги по антифрод защите сайтам A, B, C… сайты устанавливают на своих страничках(например регистрации) скрипт компании Z генерирующий фавиконы. Если пользователь зарегистрируется на сайте A, то сайты B,C уже будут знать что этот конкретный браузер связан с таким то клиентом сайта А. И допустим бан на одном из сайтов влечет за собой бан на всех других сайтах, даже если использовались разные айпи/емайлы/данные. Много сценариев, по пресечению мульти-регистрации, мошеннических действий. Возьмем пример с рекламной кампанией. То же самое, контора Z и услуга трекинга через фавикон позволит хранить отпечаток браузера и метрики пользователя о том, что он покупает или ищет в поиске на сайте C, и предоставлять информацию сайту D, когда пользователь зайдет туда, и сразу уже пойдет релевантный контент.

Правильно же я понимаю, что достаточно заблокировать домены этой ненужной прослойки в лице компании Z и вся эта схема перестанет работать?
Я о чем и говорю: если это делается через "третьих лиц", то как это можно называть уязвимостью? Некрасиво, да. Но даже в винде можно вылечить банально через hosts. Фингерпринтинг через пиксели мы же не называем уязвимостью, помоему принцип один в один.

Следящий пиксель не поможет, если использовать инкогнито. Перезапустил браузер — и ты новый пользователь для пикселя.
Favicon supercookie «пробивает» инкогнито за счет отдельного кэша для фавиконок — т.е. даже если пользователь перезапустил браузер, его supercookie останется тем же.

Если вы про фингерпринтинг на основе canvas/WebGl/шрифтов — то там проблема в том, что браузеру разрешено читать то, что отрисовано в canvas. Не знаю, что мешает производителям браузеров запретить это (или хотя бы запрашивать permission).

Если заблокировать домены — перестанет. Но это же технические домены, их можно выпускать тысячами, и это может делать и «третья» компания, и «первая» — замучаешься блокировать.
Именно. А еще — обычный рядовой пользователь не будет это всё блокировать. Можно все что угодно заблокировать или подменять, канвас тот же, вебгл хеши. Но каждое противодействие фингерпринту увеличивает ваши фрод-риск очки. И при очередной блокировке система не даст вам, скажем, совершить оплату на сайте, потому что ваш браузер уже попадает под шаблон мошеннической операции. Технологии ФП широко применяются в платежных системах, банках, магазинах, везде где есть деньги. И этим сайтам как раз нужно что бы у клиентов все цифровые следы были включены и отрабатывали именно так как это обеспечивают браузеры по-умолчанию, а не заблокированы или подменены.

Я правильно понимаю, что https://demo.supercookie.me/identity должен выдавать каждый раз одно значение?


Если так, то в обычном режиме, обычный F5 даёт разный результат на Linux/Firefox 85.0.1 вне режима Приватного просмотра.

Firefox: если обновить страницу через Ctrl+Shift+R, то отпечаток получается другим. И это с учётом того, что не установлены расширения, блокирующие получение fingerprint. Обычный режим. В Chrome не смотрел.

В 85 версии, вроде как, встраивали защиту от supercookie. Хотя, есть просто нажать на «Try Again», то отпечаток не поменялся. В принципе, это результат обычного кэширования.
Очень слабая эффективность в Chromium Version 88.0.4324.150 (Official Build) snap (64-bit)
В обычно окне только изредка поле рефреша (по F5) выдается тот же ID.
В окне инкогнито та же картина.
Но ID из обычного окна и из инкогнито — ни разу не совпали.
UFO just landed and posted this here
Между прочим, от одного из авторов статьи поступил багрепорт в багтрекер Firefox о том, что кэш favicon в Firefox работает не так, как у других браузеров (и делает невозможным применение такого способа фингерпринтинга, но об этом в багрепорте умолчали).
Версия 88.0.4324.96 (Официальная сборка), for Linux Mint (64 бит)

Инкогнито пробито.
UFO just landed and posted this here
Only those users with full accounts are able to leave comments. Log in, please.