Comments 45
Что-то из примера непонятно — этот код выполняется на сервере или в браузере?
Если я правильно понял, то атака основана на том, что браузер часть favicon-ов закеширует, а часть нет при создании отпечатка. Но при повторном визите он закеширует все остальные — т.е. эта атака одноразовая?
Нет, ведь url favicon можно генерировать скриптом
Ну и что? При первой же проверке вы на все юрл-ы сходите и закешируете их и придется еще один идентификатор генерировать. Так у вас быстро закончатся
1) идентификаторы
2) место в базе
Судя по коду, там не вполне фингерпринтинг, а персистентная кука, биты которой считываются на основании того, за какими фавиконами браузер таки пошел на сервер. То есть для пользователя просто генерируется и записывается идентификатор.
Ну так браузер пойдет за фавиконами только при первом посещении сайта, при этом он сразу же закеширует все полученные иконки, и никаких запросов при повторном посещении не будет. Поэтому мне непонятно, каким образом там собирались идентифицировать клиента. Даже если это удастся сделать в первый раз, то после первой же проверки все недостающие иконки будут дозагружены и больше никаких запросов не будет. И все браузеры станут неразличимыми.
Я всегда думал, когда глядел на окончание путей у CSS, js в виде ?random=27474838, что для браузера это каждый раз новый путь и новый файл. С favicon не проверял.
Если сервер отвечает ошибкой, то браузер ошибку не кеширует, а пробует каждый раз заново. И именно этот признак используется в режиме "чтения".
Там есть два режима — чтения (проверка идентификатора) и записи (запись идентификатора пользователя).
Идентификатор записывается редиректом по разным урлам. Это вот /a,/b,/c из статьи. По каким-то из них сервер на запрос фавикона отдает 200-ОК, по каким-то 404 (по сгенерированному заранее ID).
Соответственно чтение — прогнать пользователя по всем урлам и узнать какие фавиконы у него загружены, но при этом отправляя 404 в ответ. Т.е. при чтении браузер фавиконы и не получит (а сервер инфу получит). Если чтение показало, что фавиконов вообще нету, значит записи не было — прогоняем режим записи.
Как-то так.
Chromium 88.0.4324.150 (Official Build) (64-bit)В режиме инкогнито не сработало.
В обычном режиме по-умолчанию работает, но перестает, если принудительно обновить по Ctrl+F5.
Очень странные результаты. Если бы вообще починили, то и трекинг сломался бы во всех режимах, а так не пойми что.
В обычном режиме по-умолчанию работает, но перестает, если принудительно обновить по Ctrl+F5.
Ctrl+F5 — тоже меняет, да.
Та же версия Firefox, но трекинг не работает и в обычном режиме. На гитхабе есть информация, что как раз в 85 версии это исправили.
Firefox 85.0.2 (x64)
Windows 10 Home 1909 (build 18363.1379)
Вы скопировали чужую статью и выдаёте за свою. Ах, ну да, это называется «вольный перевод». А я называю это мусором.
обычный режим а потом инкогнито выдал одинаковые идентификаторы
<link rel="icon" href="/image.jpg" type="image/jpg">
rel="icon"
и говорит, что там указан favicon. Иногда пишут и так: rel="shortcut icon"
.Что-то я не пойму, в чем уязвимость?
Ну, допустим, используя эту "уязвимость" сайт А знает, что на него заходят с конкретного ПК не единожды… и что с того?
Сайт Б ведь никогда не узнает, что я был на сайте А. Подозреваю, что такое возможно только если оба сайта будут использовать один и тот же favicon, который лежит на другом домене, либо на домене одного из сайтов? Но такой сценарий крайне маловероятен, кто может этим воспользоваться и с какой целью?
Правильно же я понимаю, что достаточно заблокировать домены этой ненужной прослойки в лице компании Z и вся эта схема перестанет работать?
Я о чем и говорю: если это делается через "третьих лиц", то как это можно называть уязвимостью? Некрасиво, да. Но даже в винде можно вылечить банально через hosts. Фингерпринтинг через пиксели мы же не называем уязвимостью, помоему принцип один в один.
Favicon supercookie «пробивает» инкогнито за счет отдельного кэша для фавиконок — т.е. даже если пользователь перезапустил браузер, его supercookie останется тем же.
Если вы про фингерпринтинг на основе canvas/WebGl/шрифтов — то там проблема в том, что браузеру разрешено читать то, что отрисовано в canvas. Не знаю, что мешает производителям браузеров запретить это (или хотя бы запрашивать permission).
Если заблокировать домены — перестанет. Но это же технические домены, их можно выпускать тысячами, и это может делать и «третья» компания, и «первая» — замучаешься блокировать.
Я правильно понимаю, что https://demo.supercookie.me/identity должен выдавать каждый раз одно значение?
Если так, то в обычном режиме, обычный F5 даёт разный результат на Linux/Firefox 85.0.1 вне режима Приватного просмотра.
В 85 версии, вроде как, встраивали защиту от supercookie. Хотя, есть просто нажать на «Try Again», то отпечаток не поменялся. В принципе, это результат обычного кэширования.
В обычно окне только изредка поле рефреша (по F5) выдается тот же ID.
В окне инкогнито та же картина.
Но ID из обычного окна и из инкогнито — ни разу не совпали.
Инкогнито пробито.
Эффективный фингерпринтинг через кэш фавиконов в браузере