Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Onderzoekers waarschuwen voor tracking via favicons in cache browsers

Onderzoekers van de Universiteit van Chicago waarschuwen voor een methode om gebruikers op het internet te volgen met behulp van favicons. Dat zijn icoontjes die domeinen meegeven om ze makkelijk identificeerbaar maken in de interface.

De onderzoekers claimen dat een malafide domein een specifieke combinatie van favicons opslaat op de machine van een gebruiker en ze zo volgt. De favicons worden in meerdere populaire browsers opgeslagen in een cache die niet geleegd wordt of buitenspel gezet wordt in private browsing. Daardoor kan een domein een specifieke gebruiker volgen, zelfs als zij cookies blokkeren, privé browsen en andere fingerprinting-technieken dwarsbomen. Browsers melden de aanwezigheid van een relevante favicon in de cache aan de website die ze bezoeken, om zo bandbreedte te besparen.

Een malafide website zet een bepaalde combinatie van favicons op het systeem van een doelwit, waaraan ze dan te herkennen zijn bij een herhaald bezoek. Hoe groter de hoeveelheid bezoekers een website heeft, hoe meer verschillende favicons en redirects langs subdomeinen met favicons er nodig zijn. Zelfs met een website die bijna 4,3 miljard unieke browsers moet volgen, zijn 32 redirects echter genoeg. Dat kan volgens een rekenvoorbeeld van de onderzoekers in twee seconden gedaan zijn.

De onderzoekers hebben de makers van de getroffen browsers op de hoogte gesteld. Dat zijn Chrome, Safari en Edge. Google zegt al aan een fix te werken, Apple zegt naar de bevindingen van het onderzoek te kijken en Microsoft was niet op tijd bereikbaar, aldus Ars Technica. De Brave Browser was ook vatbaar, maar de makers van die browser hebben de kwetsbaarheid opgelost. Firefox hoort eigenlijk ook in het rijtje getroffen browsers, maar door een bug werkt de exploit bij die browser niet. Als workaround zouden gebruikers favicons kunnen uitschakelen, hoewel men er wel zeker van moet zijn dat ze ook daadwerkelijk niet opgeslagen worden en niet alleen niet getoond worden in de interface.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Mark Hendrikman

Nieuwsposter

20-02-2021 • 12:57

104 Linkedin

Reacties (104)

Wijzig sortering
Altijd al vermoed, eerlijk gezegd. Daarom schakel ik uit voorzorg het cache'en van favicons ook standaard uit. Geen idee hoe je dit onder andere browsers doet, maar onder Firefox doe je het zo:

Ga in "about:config" op zoek naar de sleutel "browser.chrome.site_icons". Zet de waarde op "False". Sluit daarna Firefox af. Verwijder daarna in de profielmap van Firefox vervolgens de bestanden "storage.sqlite" en "favicons.sqlite", mochten er al favicons zichtbaar zijn in je bladwijzers. Bij het opnieuw opstarten van de browser maakt Firefox de beide containers "storage.sqlite" en "favicons.sqlite" opnieuw aan, die dan helemaal schoon zijn.

Easy does it.. ;)
Dit was ook al bekend. Daarom kun je deze feature uitschakelen in Bitwarden.

Vraag me af hoe groot een database met alle favicons ter wereld zou zijn. GeoIP valt bijvoorbeeld best mee qua grootte.
Als je wilt uitrekenen hoeveel favicons je nodig hebt om 4,3 mljd unieke browser te tracken, klopt je antwoord niet. Elke favicon is een bit in je 32-bits identifier, dus 32 favicons is genoeg.

Waarschijnlijk bedoelt @Jerie trouwens gewoon een globale database van alle favicons die op het moment door sites in gebruik zijn.
Werkt deze exploit ook als javascript is uitgeschakeld?
Browsers controleren by default altijd naar een favicon op een domein. Dat zie ik vanuit de serverlogs standaard als een favicon niet op het domein staat (een 404). Dus ja theoretisch is het mogelijk; maar goed een browser per domein een favicon apart op laten slaan kost gewoon blocks aan data. Die dingen zijn amper 2KB groot en je krijgt zo enorm veel overhead als je extreem veel sites bezoekt.
Het zou wel handig zijn om voor de meest gebruikte sites zelf een icoontje op te geven, dat maakt de herkenbaarheid toch wat makkelijker als je veel tabs open hebt.

[Reactie gewijzigd door sampoo op 20 februari 2021 19:12]

Hoe herken je dan fatsoenlijk een website als je meerdere tabs open hebt, waarbij de titel van de website in elke browser ook al wordt afgepakt. Ik moet er niet aan denken dat de visuele herkenning van websites dmv de favicon niet zou bestaan.
Misschien handig om even te melden waar je dit hebt gevonden.
In de map %appdata%\Mozilla\Firefox\Profiles\<profielnaam>
Onder Help in het hamburgermenu, klik op Troubleshooting Information, about:support opent, scroll naar Profile directory en klik dan op Open directory, file opent en dan instructies volgen die Qalo beschrijft.
Dit is zo'n klassieke 'nvm i fixed it' comment ;)! Je zou even een link/beschrijving kunnen plaatsen voor de volgende lezer die het niet kan vinden :P
Het blijkt dat deze onderzoekers nogal onetisch te werk zijn gegaan.

https://twitter.com/antumbral/status/1352569510692179969

Ze hebben een bug report naar Mozilla gestuurd en als deze 'bug' gefixt zou zijn zou daarmee deze attack vector ook mogelijk zijn geworden op Mozilla. Ze hebben niks gezegd over dat de reden was om een aanval te kunnen testen, het lijkt erop dat de enige reden om die bug te reporten was zodat ze een 'sterker' paper zouden hebben.

Het lijkt er ook niet op dat ze ooit van plan waren Firefox te informeren over het waarom. Bewust proberen exploits toegevoegd te krijgen aan software lijkt me niet hoe een beveiligingsonderzoeker zich zou moeten gedragen...
De tweet is niet meer beschikbaar, dus ik link even de bron: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

De reactie van de onderzoeker hierop:
To provide additional details and context about our disclosure process: Our bug report was submitted to Firefox in February 2020 while we were still trying to understand how different browsers fetch/process/store favicons. Once we had devised the technique detailed in the paper and run experiments to see which browsers were susceptible, we informed all vulnerable browsers (June 2020). Our disclosure process took place before we submitted our paper and many months before publicizing our findings (February 2021), to allow browsers ample time to address this issue and prevent any users from actually being tracked in practice. Not notifying Firefox at that time was our oversight because we were focused on notifying the vulnerable browsers. In hindsight, we agree that we should have proactively notified Firefox. We hope that the continued conversations we had with other vendors to get the bug fixed shows that we had the best interests of web users at heart, and that neglecting to circle back with Mozilla once we found the security bug was an oversight rather than due to malice on our part.
Ze zeggen dat ze domweg vergeten waren om Mozilla te informeren. Ik heb niet echt aanwijzingen gezien dat we hierbij van de slechtst mogelijke bedoelingen zouden moeten uitgaan. Twitter doet dat uiteraard wel, altijd boos boos zonder dingen uit te zoeken.

[Reactie gewijzigd door Cerberus_tm op 21 februari 2021 03:37]

Hoewel deze methode al heel oud is (is al uitgebreid gedocumenteerd in 2013 inclusief implementatie op stack overflow: https://stackoverflow.com...sit-to-a-website/16933618 en dat was naar aanleiding van een vraag die weggemodereerd is), is dit in de EU volgens mij nog steeds niet toegestaan zonder consent.

Men is kompleet doorgeslagen met cookiewalls en dingen als “legitimate interest” vinkjes. Had net nog een website waar ik 5 minuten bezig ben geweest om alle vinkjes uit te zetten (kuch dailymail).

De mensen die dit soort hoepels verzinnen verdienen wat mij betreft dan ook celstraf. Je wordt gewoon verkocht bij opbod.

In dit geval kost het ook nog eens resources van de client. 32 HTTP calls voor een stom icoontje is natuurlijk bizar en op instabiele lijnen kan dit behoorlijk wat tijd kosten. Je verpest dus de UX doordat je mensen per se wil tracken zonder consent. Dit is niet waar het web voor is bedoelt.
Dat zijn icoontjes die domeinen meegeven om ze makkelijk identificeerbaar maken in interface.
Een favicon staat toch op de hosting server van de website? Of kan een favicon ook via een domeinnaam verspreid worden?
De browser cached een favicon. Ik heb me hier nog niet in verdiept, maar ik vermoed dat de website dan gewoon kijkt of een browser de favicon wel of niet op komt halen. Als de filename, bytesize enzo identiek zijn als wat de browser al in de cache heeft zitten, gaat het niet de favicon opnieuw downloaden en trekt het deze weer uit de cache.

Geef elk IP bv zijn eigen setje favicons. Combineer dat dan weer met X aantal favicons via redirects naar verschillende domeinen die wel of niet gecached zijn en tadá, fingerprint.

[Reactie gewijzigd door batjes op 20 februari 2021 13:17]

Dit is volgens mij precies wat er gebeurt. De malafide website checkt of een bezoeker het eerste favicon wel of niet komt ophalen, doet een redirect naar ULR 2 en kijkt daar weer of het favicon wordt opgehaald, doet een redirect naar URL 3, enzovoort, tot en met URL 32. Zo ontvangt de website via de 32 URL’s 32 keer een binaire waarde (wel of niet favicon ophalen). In totaal levert dat 232 = 4,3 miljard mogelijkheden op. Als iedere terugkerende bezoeker een andere set favicons in zijn cache heeft staan door zijn vorige bezoek, zijn ze stuk voor stuk uniek herkenbaar.
Vreemd dat de verschillende browsers daarop in gaan. Voor de pagina zelf staat bijv. Chrome nauwelijks nog redirects toe; wordt je doorverwezen, dan moet je daar stuk voor stuk handmatig mee akkoord gaan.
Hoogstens naar externe domeinen waarbij je met een kluitje het riet ingestuurd wordt. Op vrijwel iedere request naar een non https link krijg je meestal namelijk eerst een 302 terug naar de SSL variant (HTTPS).

Het internet functioneerd niet zonder redirects.
Ik vraag me af hoe hij wordt gecacht, kan je de favicon inderdaad manipuleren voordat je hem serveert naar de browser zodat elk favicon unique en dus trackbaar is.
Je hoeft het icoontje zelf niet te manipuleren, je moet alleen weten welke icoontjes de bezoeker op zijn systeem heeft staan.
Het icoontje van Tweakers kan als een onderdeel zijn van een unieke vingerprint.
jij als gebruiker ziet het verschil niet maar je kunt schijnbaar niet bewust na kijken welke icoontjes van welke websites op jou systeem staan en de onbekende daarna wissen.
1x per 2 á 3 maanden gooi ik mijn volledige cache leeg/weg maar juist dit gedeelte kan ik dus niet terug halen en wissen dus daar zit een behoorlijke fout.
Als je geen unieke favicons gebruikt, werkt dat maar 1 keer. Na het tweede bezoek is dan elke favicon gecached.

Maar unieke favicons genereren is niet zo moeilijk met een url rewrite en php gd library bv.
Wat ze volgens mij doen is zelf subdomeinen opzetten met eigen favicons. Die subdomeinen doen verder helemaal niks, het feit of de favicon wel of niet gecached is wordt gewoon gebruikt als 'bit'. Het favicon is er wel of niet, dus een 0 of een 1. Daarom staat er dat je met 32 redirects zo'n kleine 4,3 miljard unieke browsers kunt volgen. Een kleine 4,3 miljard, dat is 2 tot de macht 32, oftewel het aantal unieke combinaties wat je met 32 bits uit kunt drukken.
Je begrijpt dat de cache van je browser geen rekening houdt met een bestandsnaam, enkel met de volledige URL, die hij mee bewaart. Wat de filename is (op je PC in je cache) is daarbij niet relevant.
Dit is een taalkwestie: de domeinnaam heeft er niet letterlijk mee te maken, maar het favicon dient als identificatie voor een website/domein. Natuurlijk wordt het pictogram verspreid door een hosting server zoals alle website assets. In de volkmond kun je spreken van "het domein geeft dat mee", min of meer, ook al klopt het strikt technisch niet helemaal.

On topic: hopelijk kunnen browser-bouwers hier iets op verzinnen. In het ergste geval door favicons helemaal niet meer te cachen; het zijn niet bepaald de zwaarste of grootste assets. Of door de favicon-cache bij de "gewone" cache te trekken o.i.d. zodat dezelfde gebruiker niet meer privé en niet-privé gevolgd kan worden.

[Reactie gewijzigd door geert1 op 20 februari 2021 13:17]

Als je een randomizer erin zet dat 50% van de tijd favicons gecached worden, dan maak je dit al onbruikbaar lijkt me?
Ik heb niet naar het onderzoek gekeken maar ik vermoed dat het te maken heeft dat een browser vanuit zichzelf een favicon opvraagt. Als ontwikkelaar vond ik dat sowieso al vervelend. Soms bouw ik vrij snel een API endpoint met een wildcard om even te testen/debuggen. Vervolgens als ik met mijn browser er naar toe ga, dan kreeg ik opeens twee requests binnen. Blijkt dus het originele request te zijn, bijvoorbeeld; /test maar dan ook nog automagisch /favicon.ico
Inderdaad gek dat dat nog steeds gebeurt. Als je in je HTML geen icon opgeeft moet de browser niet zelf gaan vissen vind ik.
Het is gewoon een hele basic feature van een webserver. Dat bestandje moet in de HTML root staan en dan werkt het. Zit er ook al eeuwen in. Best slim gevonden deze 'exploit'.
Firefox hoort eigenlijk ook in het rijtje getroffen browsers, maar door een bug werkt de exploit bij die browser niet.
Grappig hoe een bug tegelijkertijd als fix kan dienen.
Echt correct is het eigenlijk niet. Dit is alleen van toepassing op Linux aangezien er daar blijkbaar een probleem is bij het ophalen van favicons uit de cache. Dus op Windows of Mac is deze manier van tracking dus even goed mogelijk op Firefox.
Als ik het goed begrijp werkt dit enkel binnen 1 en hetzelfde domein. Ik zie het probleem dan niet zo goed, die info is toch gewoon te vinden in de browser logs, tenzij een gebruiker echt heel erg hard zijn best doet om dat te vermijden. Maar zo interessant is deze "tracking" dan toch helemaal niet?
Favicon tracking is alleen nuttig voor de website die de gebruiker bezoekt, en waarbij de gebruiker private browser mode gebruikt, of zijn/haar cookies heeft gecleared. Als dat niet het geval is, dan had de website de gebruiker gewoon kunnen tracken met simpele cookies. Dus de inzet mogelijkheden van deze tracking methode zijn inderdaad vrij beperkt, maar kunnen wel voor bepaalde websites (zoals websites als Facebook) wel interessant genoeg zijn om te implementeren.
Best een gedbed zonder eind..., dat tracking verhaal. Valt weinig aan te doen.Goed teken dat Brave deze tracking methode zo snel heeft opgelost. Ik moet zeggen dat Ublock origin en Ghostery echt vrijwel niets meer te doen hebben sinds ik Brave gebruik :). Fijn ook dat alle extensies die ik in Chrome had gewoon in Brave werken. Bookmarks zijn makkelijk importeerbaar.

@JackDashwood : Zoals ze in het artikel zeggen worden favicons ook gecashed om bandbreedte te besparen

[Reactie gewijzigd door Tierelier op 20 februari 2021 13:08]

Brave doet vooral heel stoer over vanalles maar is ook niet perfect (mompelt iets over .onion naar DNS sturen...). Wat jij waarschijnlijk ervaart is gewoon het gebruik van een schone browser, zonder plug-ins etc. Firefox is lang zo slecht nog niet namelijk.
Ik gebruik op brave dezelfde plugins op het moment. 1Pass en ghostery. Heb het vaakste gehad met firefox dat een webpagina niet reageert en zodra ik de pagina sluit, begint de RAM vol te lopen. Ik weet niet waar dat aan ligt. Mijn pc is aardig krachtig, maar zelfs dan zou de RAM niet moeten vollopen door een doorgeslagen webpagina
Firefox hoort eigenlijk ook in het rijtje getroffen browsers, maar door een bug werkt de exploit bij die browser niet.
Hier moest ik wel even om lachen!
De favicons worden in meerdere populaire browsers opgeslagen in een cache die niet geleegd wordt of buitenspel gezet wordt in private browsing.
WTF?

Een favicon is toch net zo goed data uit het boze internet? Hoezo zou die favicons blind te vertrouwen zijn?

Dit tracking mechanisme rust op de verkeerde implementaties van nagenoeg alle browser censors.
Tis ook van de zotte dat een favicon word gecached. Alleen google al openen kost kilo's aan data (1.5MB minimum).


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone 12 Microsoft Xbox Series X LG CX Google Pixel 5 Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True