Browser 'Favicons' Can Be Used as Undeletable 'Supercookies' To Track You Online (vice.com) 35
According to a researcher, favicons can be a security vulnerability that could let websites track your movement and bypass VPNs, incognito browsing status, and other traditional methods of cloaking your movement online. From a report: The tracking method is called a Supercookie, and it's the work of German software designer Jonas Strehle. "Supercookie uses favicons to assign a unique identifier to website visitors. Unlike traditional tracking methods, this ID can be stored almost persistently and cannot be easily cleared by the user," Strehle said on his Github. "The tracking method works even in the browser's incognito mode and is not cleared by flushing the cache, closing the browser or restarting the system, using a VPN or installing AdBlockers."
Strehle's Github explained that he became interested in the idea of using favicons to track users after reading a research paper [PDF] on the topic from the University of Illinois at Chicago. "The complexity and feature-rich nature of modern browsers often lead to the deployment of seemingly innocuous functionality that can be readily abused by adversaries," the paper explained. "In this paper we introduce a novel tracking mechanism that misuses a simple yet ubiquitous browser feature: favicons." To be clear, this is a proof-of-concept and not something that Strehle has found out in the wild.
Strehle's Github explained that he became interested in the idea of using favicons to track users after reading a research paper [PDF] on the topic from the University of Illinois at Chicago. "The complexity and feature-rich nature of modern browsers often lead to the deployment of seemingly innocuous functionality that can be readily abused by adversaries," the paper explained. "In this paper we introduce a novel tracking mechanism that misuses a simple yet ubiquitous browser feature: favicons." To be clear, this is a proof-of-concept and not something that Strehle has found out in the wild.
Firefox not vulnerable (Score:5, Informative)
Due to a bug of it not looking up anything in the favicon cache...
for those asking Chrome safari edge and brave are vulnerable.
Re: (Score:3)
Why should it go and look up everything in the favicon cache ? Seems to me if the web site gave me an icon once, I can keep that icon until I actually visit that site again. Otherwise just opening the menu is going to cause a whole bunch of address lookups and data fetches which is really stupid to do just to present a flashy thing on a menu.
Re: (Score:2)
Why should it go and look up everything in the favicon cache ? Seems to me if the web site gave me an icon once, I can keep that icon until I actually visit that site again. Otherwise just opening the menu is going to cause a whole bunch of address lookups and data fetches which is really stupid to do just to present a flashy thing on a menu.
Seems like weirdow is saying that the cache lookup is broken, if that's the case then it would do the dumb thing that you have described...
Clarification and Qualification (Score:5, Informative)
If you go all the way through the the author's own post on the subject (here [supercookie.me]) and scroll down, you will find a table showing different browsers and different operating system combinations.
The author shows that Firefox on Linux, iOS and Android is not vulnerable, but on Windows and MacOS it is.
So weirdow's statement would be correct if they were using Linux, iOS or Android only.
Hope that helps.
Re:Firefox Intentionally not vulnerable (Score:5, Interesting)
As of Firefox 85, it is intentionally not vulnerable, because nearly all persistent caches (including favicon) are now partitioned according to top-level domain [mozilla.org] which blocks a ton of methods used for super-cookies. Other browsers have been implementing similar protections.
Re: (Score:2)
This is irrelevant to this attack since the paper is not trying to move data across top-level domains.
Furthermore, the partitioned caches do not prevent passing data through the redirect itself. e.g http://domaina.com/favicon.ico [domaina.com] redirects to http://domainb.com/domainA-ID-... [domainb.com] which redirects to http://domaina.com/domainB-ID-... [domaina.com]
Re: (Score:3)
Re: (Score:2)
You can block this with an ad blocker. Just create a rule that blocks all favicons.
Spoiler (Score:4, Informative)
The technique uses the favicon cache and a chain of redirects to build up a bit string that can be inferred from the server logs.
Re: (Score:2)
But... what the hell is a favicon?!?
Re: (Score:2)
Honestly though... they got well correlated ip address for you most of the time. Pretty sure that this sort of "super cookie" is mooted by that.
You would have to use a VPN full time AS WELL AS take EXTREME CARE to avoid tracking. If you ever log in with an identity anywhere, it has to be on a fresh vpn connection, and that you dont do anything else at all with that connection... because that act of logging in tagged that vpn traffic directl
This is subtly brilliant (Score:3)
I wonder if we're about to see a bunch of cache/redirect based attacks; leveraging 301/302's for keeping state, etc.
Thanks a lot HTTPS! (Score:2)
Re: (Score:2)
By ditching transparent HTTP caching proxies at ISPs (since HTTPS can't be cached without interception), anything which uses ETags can be abused for supercookies very easily. I suppose that's still a lot better than things were before though...
Well, maybe. Depends on your threat model I suppose. In the days of smaller ISPs (or leased-lines going to somewhat trusted endpoints), an HTTP proxy effectively hid a lot of stuff behind all of the ISPs customers in your region/area/segment. There are times when that's probably a fair trade over encrypted-but-tracked like we have today, at least for consumers not under state-level attack vectors who just don't want as much derivable about them directly. This is probably even moreso the case in the modern d
Curious (Score:2)
This attack could be performed with any cacheable resource (like an image) - no need to limit it to favicon (although using an image would require an actual redirect to a page, and would probably be more visible)
Re:Curious (Score:4, Informative)
Actually most browsers will follow 302s on img tags. So they could probably be used. The advantage of the fav-icon was that its not cleared if the user clears the cache and not subject to the just this session rule incognito and private browsing modes are.
Also - easy fix for Firefox (Score:5, Informative)
aboug:config -> browser.chrome.site_icons -> toggle "false"
Is this really new news? (Score:1)
Favicons have been a security hole since their inception. How do people still not know this?
Re: (Score:2)
Re: (Score:1)
Google fonts are literally a link to a woff2 file. how is that spyware?
Because, dipshit, you can enumerate the users installed web fonts with a little bit of web javascript. Fingerprint successful, douche bag.
Adversaries? (Score:2)
Re: (Score:1)
If if you're really, really careful, after all that work, you'll be rewarded with glorious outcome of only being advertised stuff that's not relevant to you.
Re: (Score:2)
.... you'll be rewarded with glorious outcome of only being advertised stuff that's not relevant to you.
I'd prefer that, it is less creepy. If I want to buy something I will initiate my search of the market myself. In fact I don't see any adverts unless they are an integral part of the web page because I block them..
someone should make a chrome/chromium extension (Score:2)
Re: (Score:2)
what you do with all other images, as this also applies to all images!
Move it to DNS? (Score:1)
Maybe favicons could be better implemented as a general DNS based solution to associate small images with any names independent of web apps. That would make them more efficient and less easy to abuse to track users.
So something like dig IMG _logo._png.faphorse.com gets you a base64 encoded image of the type requested. Some images could fit in a TXT record.
A More Fundamental Problem? (Score:2)
After what? 50 years of personal computing, we no longer bother to stop and think about the idea that software is continually updated with new features. As end users of software, we pay for these features one way or another: if we’re using commercial software, then the sticker price reflects the effort required to design, develop and debug ever more complex code... If we’re using “free” (as in beer) software, we’re stil
Time to start naming&shaming coders who... (Score:2)
write browser code that allows ANY web-page hosted script code to access ANY local system cache, ANY local system files, ANY local browser resources like bookmarks, faveicons, or cookies originating from any website other than the one that stored them. If my computer is running ANY code from a remote location, then it is NOT secure and arguably is not really MY computer. Any computer used to browse the web and run any random code that it encounters along the way is to computing security problems, as guy who
Re:Time to start naming&shaming coders who... (Score:4, Interesting)
write browser code that allows ANY web-page hosted script code to access ANY local system cache
I think it's the opposite, the lack of a GET request for a favicon tells the server that the tracking image is in the user's cache.
They use a binary system, so say 32 different favicon paths. First the JS generates a 32 bit random integer. Next it generates the set of favicon paths/redirects for the page based on each 1 bit in the random number (e.g. 0/favicon.ico, 4/favicon.ico, 5/favicon.ico .... 29/favicon.ico). The browser then requests and caches this set of icons. The random id is now 'stored' on the host.
On a later page trying to read the stored id, it generates the complete set of 32 favicon paths (0/favicon.ico... 31/favicon.ico). Your browser will only request the uncached paths, the '0 bits'. In this mode the server will return a 404 for each request to avoid changing the cache, and it can construct the id by filling in the '1 bits'. Now you are tracked across the two pages.
This might be defeatable by limiting the amount of favicon requests allowed per page to some sensible number. If it were 4, the tracking false hits would be very high.
We need intercepting proxies... (Score:2)
Move all this work into a proxy. Have one place responsible for all of this and all the browsers then talk to a "proxy" on localhost via http.
Back in the good old http days this wouldn't have worked nearly as well as everybody along the path would be proxying these favicons.
By moving them to https the website has a direct connection to the browser and fetch/not fetch conveys a bit of information.
Mozilla already wants to do all your DNS for you in the name of anonymity/security. Will the next thing be them r