Safari-kwetsbaarheid kan internetactiviteit en gebruikersidentiteit blootleggen

Apples Safari 15-browser bevat een kwetsbaarheid waarmee elke website de internetactiviteit van de gebruiker kan volgen. Ook kan de kwetsbaarheid de identiteit van de gebruiker onthullen. FingerprintJS, een fraudedetectiedienst voor browsers, ontdekte dat.

FingerprintJS schrijft op zijn blog over de kwetsbaarheid in de vorm van de implementatie van de IndexedDB-api. De kwetsbaarheid zit niet alleen in Safari 15 op macOS, maar ook in alle browsers op iOS en iPadOS 15. De implementatie van deze api in Safari 15 betekent dat elke keer als een website een verbinding maakt met een database, een nieuwe lege database met dezelfde naam wordt gecreëerd in alle andere frames, tabbladen en vensters in dezelfde browsersessie. Dit is volgens FingerprintJS een schending van het same-origin-beleid.

IndexedDB is bedoeld voor client-side storage, bevat nogal wat data en wordt door alle grote browsers ondersteund. Net als veel soortgelijke api's hanteert Indexed DB het same-origin-beleid. Dat betekent dat er restricties van kracht zijn bij hoe scripts of documenten die vanuit een bepaalde bron worden geladen en dat die niet zomaar in verbinding kunnen staan met een andere bron.

Volgens FingerprintJS wordt dat principe geschonden en is het feit dat de databasenamen kunnen uitlekken over meerdere bronnen een duidelijke privacyschending. Het maakt het mogelijk dat willekeurige websites erachter kunnen komen welke websites de gebruiker bezoekt in andere tabbladen of vensters. Volgens de dienst is dit mogelijk, omdat databasenamen doorgaans uniek en websitespecifiek zijn.

Daarbij wijst FingerprintJS ook specifiek op het feit dat in sommige gevallen websites unieke, gebruikersspecifieke identifiers in databasenamen hanteren. Dat betekent dat geauthenticeerde gebruikers heel precies kunnen worden geïdentificeerd. Daarbij worden YouTube, Google Calendar of Google Keep genoemd als voorbeelden van sites die databases creëren met daarin de geauthenticeerde Google User ID. Als de gebruiker is ingelogd op meerdere accounts, worden er databases voor al deze accounts aangemaakt. Aan de hand hiervan kunnen malafide websites de gebruikersidentiteit achterhalen en zijn meerdere, aparte accounts van dezelfde gebruiker toch aan elkaar te koppelen.

De kwetsbaarheid treft niet alleen Safari 15 op macOS, maar ook alle browsers op iOS en iPadOS 15, omdat die allemaal in navolging van Apples App Store-voorschriften de WebKit-engine gebruiken. Volgens FingerprintJS kunnen gebruikers weinig tegen deze kwetsbaarheid doen, buiten het nemen van 'drastische maatregelen', zoals het standaard blokkeren van alle JavaScript en het alleen toe te staan op sites die worden vertrouwd. FingerprintJS zegt dat er maar een echte oplossing is: het updaten van de browser of het OS zodra het issue door Apple is verholpen. Dat laatste is nog niet gebeurd. De kwetsbaarheid werd op 28 november vorig jaar gemeld.

Reacties (98)

[markg85]

Voor wie het niet doorheeft, het is een WebKit bug en de patch zit sinds vandaag in de source: https://github.com/WebKit...88f8ee447de23927749fb56e5

Misschien handig om aan het artikel toe te voegen?

Feitelijk een one-liner fix. Maar wel netjes dat ze er nu ook gelijk op testen dat het niet meer voor kan komen. Dit is dan wel het mooie van open source

Wel naar voor de browsers op basis van webkit... Kijk, safari zal wel snel updaten aangezien die nu deze negatieve publiciteit hebben. Maar de andere webkit gebaseerde browsers (zag hier bijvoorbeeld epiphany van Gnome langskomen) kunnen best nog wel eens een tijdje duren. Beetje afhankelijk van je Linux distributie.

[Reactie gewijzigd door markg85 op 22 juli 2024 15:59]

[Tjolk]

De patch zit erin, maar is nog niet gereleased. Kijk je in de laatste release tag versie van Webkit dan is dat Safari-15.2-iOS-15.2 van vorige maand. Het lijkt er nu sterk op dat dit gefixt is enkele uren na de publicatie van het lek.

[PuzzleSolver]

Slordig van Safari, ik gebruik zelf ook IndexDB voor opslag in een applicatie. Als je de naam dus weet van die database kunnen andere websites dus zien of er iemand op mijn site is geweest. Ik zie dat youtube zelfs 15 IndexDB databases heeft aangemaakt waarvan het grootste deel een ID heeft in de naam, als die lijst van database namen dus te achterhalen is dan is dat best triest. Ik heb hier geen safari, maar iemand zou dit in safari kunnen testen met het commando

indexedDB.databases().then(r => console.log(r))

in de javascript console.

[rnark]

Dit werkt inderdaad. Ik gebruik standaard geen Safari, maar als ik Nu.nl open in tabje 1 en vervolgens je code draai krijg ik eerst een lege array terug. Vervolgens open ik in tabje 2 YouTube. Wanneer ik daarna in tab 1 de code nogmaals draai krijg ik:

[Log] [{name: "ServiceWorkerLogsDatabase", version: 1}, {name: "YtIdbMeta", version: 1}, {name: "yt-it-response-store:FTcJLyFn22c||", version: 1}, {name: "LogsDatabaseV2:FTcJLyFn22c||", version: 9}] (4)

[Reactie gewijzigd door rnark op 22 juli 2024 15:59]

[GertMenkel]

Ik kan dit reproduceren in GNOME Web (Epiphany) dus het lijkt in WebKit in het algemeen te zitten.

Ik open Github.com, krijg een lege array. Open Youtube.com, vraag opnieuw de database van Github.com op en krijg allemaal Youtubedingen.

Ik hoop dat hier snel wat aan wordt gedaan want de meeste Webkitbrowsers hebben best een uitgebreide privacybescherming toegevoegd die hier compleet onbruikbaar door wordt gemaakt.

[Jerie]

Bevat Chrome dit lek ook?

[GertMenkel]

Op iOS: ja, omdat Apple ontwikkelaars verbiedt om hun eigen browser engines in de app store te zetten. Chrome, Firefox, Opera, noem maar op, ze hebben onder water allemaal dezelfde engine.

Op alle andere platformen: nee, Chromium en vrienden zijn een tijd geleden van WebKit naar Blink overgestapt en Blink heeft hier geen last van.

[PuzzleSolver]

Dat is dan best wel een ernstig lek wat privacy betreft dus, aangezien veel mensen wel een tabje open hebben staan met youtube of iets anders waar ze op ingelogd zijn. Net even een aantal tabs hier bekeken.

GMail, Meet en Google Docs zijn te detecteren maar hebben geen ID in de naam.
Tweakers heeft geen IndexDB.
Van nu.nl heb ik ook nog een "test" en een "1" database staan, waarschijnlijk ooit aangemaakt omdat ze testcode op hun site hadden.Verder geen ID's in namen.

[Reactie gewijzigd door PuzzleSolver op 22 juli 2024 15:59]

[Blokker_1999]

Dit heeft heel weinig met java te maken. Zeg zelf maar niets.

IndexedDB is een technologie voor het lokaal kunnen opslaan van data en wordt door alle browsers al heel wat jaren ondersteund. Nu heeft Apple in zijn nieuwste broserversie dus een fout gemaakt waarmee bij de aanmaak of het gebruik van zo een database, de naam en dus het bestaan ervan zichtbaar wordt voor alle tabbladen. Elke website kan nu dus opvragen welke databases er zijn, en dat kan bijvoorbeeld met javascript. Javascript heeft trouwens helemaal niets te maken met Java.

Ook de rest van heel je rant ontgaat me een beetje. Ja, op een gegeven moment eindigt de ondersteuning voor een product. Dat is algemeen gekend en meestal goed op tijd geweten. Dat computers geen 20 jaar meegaan weten we allemaal. Waarom dan zo afgeven op het feit dat verouderde hardware op verouderde software draait en bugs niet opgelost geraken? Iets wat hier trouwens ook niet van toepassing is omdat je terug kunt naar versie 14 van Safari, kunt wachten op een bugfix in Safari of een andere browser kunt gebruiken.

[Keypunchie]

Java =/= JavaScript. Behalve de naam die een beetje op Java lijkt heeft het weinig met elkaar te maken.

Probeer trouwens maar JavaScript standaard uit te zetten en nog op een normale manier van het web te genieten.

Dat gaat voor geen meter, en ik kan het je uit ervaring vertellen, want ik probeer het door middel van gebruik van NoScript.

Het is niet te doen. Ik draai NoScript daarom met een stuk meer permissies, maar elke site die je toestaat om JavaScript te draaien kan dit lek exploiteren.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 15:59]

[HADES2001]

Ga een dagje googlen naar Java en Javascript en kom daarna even terug want die twee zijn echt compleet andere dingen. Beetje hetzelfde als zeggen dat Planet Internet samen zit met Planet Pizza

[DefaultError]

Het zal de eerste niet zijn die er een issue van maakt;-) Java & Javascript ligt voor mij net zover uit elkaar als voetbalveld.

[iAR]

Als je software maakt dan is dat nooit perfect. Bij niemand. Je opmerking om te zeggen 'Apple maakt het zoveel veiliger' direct als achterhaald te markeren is is net zo kort door de bocht als denken dat java en javascript hetzelfde.

[gimbal]

In 2022 nog steeds java en javascript door elkaar gooien is wel erg slordig hoor. Javascript is hier om te blijven, dat gaat nooit meer weg. Het halve web is er intussen al op gebouwd.

[this]

Java en Javascript is zoals ham en hamster.
Ze bevatten dezelfde letters, maar dat is het dan ook.
Ze zijn dus absoluut niet door elkaar te gebruiken. Als je het over java hebt, gebruik dan java. Praat je over javascript, gebruik dan javascript. En niet java/script, dat slaat gewoon nergens op.

[markg85]

ham en hamster... +3 voor awesome comment, echt geweldig

[this]

Je bent wel een erg volhardende trol. Raar dat je een tweaker hero zou zijn.

[GertMenkel]

Betalende trollen blijven trollen.

[DefaultError]

Ik wil heel graag dat een device niet op een voetstuk staat omdat het nu eenmaal een geweldig ding is maar dat het, gezien de populariteit, veilig blijft.

De kwetsbaarheid mag best benoemd worden en uit zijn verband gehaald worden. Geen vragen meer aka @this?

[TooMuchRAM]

Zowel Java als JavaScript vallen in een heel andere categorie dan Flash. Adobe Flash player was een plugin voor browsers om interactieve content mogelijk te maken, en Flash had haar eigen taal. Flash is beter te vergelijken met V8 (JS) of de JVM (Java) bijvoorbeeld. Java en Javascript zijn programmeer/scripttalen, en talen zijn nooit onveilig; ze moedigen hoogstens onveilige programmeergewoontes aan.

[RienBijl]

talen zijn nooit onveilig

Dit is niet waar, talen kunnen prima onveilig zijn. Dat kunnen programmeerfouten zijn die later misbruikt worden, of directe gerichte aanvallen zijn, zoals destijds bij PHP. https://tweakers.net/nieu...ectie-van-git-server.html

Iets accurater, een beveiligingsfout in een applicatie ligt vaker bij de eind-ontwikkelaar, dan bij de leverancier van de programmeertaal.

[Reactie gewijzigd door RienBijl op 22 juli 2024 15:59]

[TooMuchRAM]

Dat is wat ik bedoelde met:

ze moedigen hoogstens onveilige programmeergewoontes aan

Sommige talen hebben gewoon een handleiding nodig, en bij PHP is die wat langer dan bij andere talen.

Iets accurater, een beveiligingsfout in een applicatie ligt vaker bij de eind-ontwikkelaar, dan bij de leverancier van de programmeertaal.

Klopt, iets beter verwoord.

[Reactie gewijzigd door TooMuchRAM op 22 juli 2024 15:59]

[R4gnax]

Dit is niet waar, talen kunnen prima onveilig zijn. Dat kunnen programmeerfouten zijn die later misbruikt worden, of directe gerichte aanvallen zijn, zoals destijds bij PHP. https://tweakers.net/nieu...ectie-van-git-server.html

De runtime component waarop je programma draait of de compiler waarmee je programma gecompileerd wordt, is niet hetzelfde als de taal waarin je je programma schrijft.

[RienBijl]

Om het nog accurater te maken, ja, de taal als abstract iets kan geen beveiligingsfouten bevatten. In praktische zin natuurlijk wel, omdat het zonder compiler of runtime volstrekt onbruikbaar is.

[PuzzleSolver]

Talen kunnen wel ontworpen zijn met betere veiligheid in gedachte.Zo is RUST b.v. gebouwd om de bufferoverflow problemen van C++ op te lossen. Geheugen management is een ander veel voorkomend probleem, vooral het vrijgeven van het geheugen en daarna nog per ongeluk kunnen gebruiken. Talen die ontworpen zijn om met een garbage collector te werken zoals Java en C# (en alle andere talen voor het .NET platform) zijn daarom ook weer wat veiliger. Deze beheren het geheugen voor je en stoppen het weg achter referenties die door een runtime beheerd woden. Verder heb je b.v. nog Typescript dat is bedoeld on de type problemen van javascript aan te pakken en maakt het op die manier ook weer wat veiliger.

En al deze veiligheden hebben niets te maken met de bug in het artikel. Dat was gewoon een foute implementatie van een API die vanuit javascript gebruikt kan worden. Een andere taal had dat niet opgelost. Deze bug kwam omdat iemand die de browser onderhoud (waarschijnlijk in C++ of gebruikt Apple daar ook Swift of Objective C?) de tabs niet goed van elkaar gescheiden heeft als het om de indexdb databases gaat. Misschien een optimalistie met onbedoelde bijwerking?

[R4gnax]

Om het nog accurater te maken, ja, de taal als abstract iets kan geen beveiligingsfouten bevatten. In praktische zin natuurlijk wel, omdat het zonder compiler of runtime volstrekt onbruikbaar is.

Dus: JavaScript is niet onveilig.

De specifieke implementatie in Safari/Webkit van het stukje native functionaliteit onder de noemer IndexedDB - wat aan te spreken is via JavaScript - is nu onveilig.

[RienBijl]

Ik heb dan ook niet gezegd dat Javascript onveilig is.

[Xander2]

Een construct als eval zit wel op het randje wat mij betreft.

[R4gnax]

Flash had haar eigen taal.

Technisch gezien niet.
Flash is een commerciële implementatie van het nooit verder gepubliceerde ECMAScript 4 geweest, welke als voornaamste toevoeging bovenop ES3 een opt-in type-system en OOP classes zou hebben gehad. De gemoederen hierover liepen zo hoog op dat de stekker er finaal uitgetrokken werd en dat hele versienummer gelaten werd voor wat het was terwijl men zich op ES5 ging richten.

Dat type-system is er nooit van gekomen, en TypeScript is in die niche gesprongen. Classes kwamen uiteindelijk pas in, als ik me goed herinner, ES6.

Flash als programmeertaal was dus zeg maar een shitty versie van TypeScript, zonder alle niceties zoals automatische type inference. En met een absolute draak van een editor die erbij door je strot geramd werd.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:59]

[DefaultError]

Ben alsnog benieuwd waarom Edge en Chrome geen kwetsbaarheid geeft bij Java-script en Safari wel. Waar ligt de grondslag van dit ogenschijnlijke architectuur afhankelijke zere plek?

[TooMuchRAM]

Implementatie. Edge en Chrome draaien allebei op Blink/V8 terwijl Safari draait op WebKit. Blijkbaar zit er dus een foutje in WebKit die het uitlezen mogelijk maakt.

[DefaultError]

Voor hoe lang al?

[DefaultError]

Voor mij één pot nat, Java/Javascript. Programmeertaal of programmeerscript is voor mij gelijk aan elkaar. Ik wil wel graag dat het veilig is of dat het veiliger gemaakt wordt. Ook gek trouwens dat Windows en Linux geen hinder hebben, hoe kan dit zich verhouden tot Apple in dat geval?

[Rmaxx]

Ik heb deze rant met veel plezier gelezen. Dus als automerk (apple) een auto (browser)maakt waarbij ze een keer vergeten de remmen vast te schroeven (gevaarlijke bug), zeg jij :schijfremmen of trommelremmen (java/script..hilarisch), maakt me niet uit weg ermee!.. top man

Heerlijk dit

[DefaultError]

🤘

[Ossebol]

In hoeverre treft dit Blinkgebaseerde browsers, zoals Chrome en Edge? Blink is een fork van WebKit dus wellicht zit deze kwetsbaarheid hier ook in. Dan zou het véél groter zijn dan enkel Safari. Weet iemand dit?

Ook interessant: volgens het bronartikel ben je in Safari in principe 'veilig' als je een incognitosessie start, omdat alle incognito-tabs een andere sessie hebben. Als je echter binnen dezelfde tab naar een andere site surft, kan die site wél bij de overige data uit de IndexedDB komen. In andere WebKit-browsers, zoals Chrome op iOS dus, zouden alle incognito-tabs dezelfde data delen, waarmee je dus met tab x data uit tab y kunt lezen (als ik het goed begrijp).

[Reactie gewijzigd door Ossebol op 22 juli 2024 15:59]

[Anonymoussaurus]

Chrome en Edge lijken niet affected, net getest via https://safarileaks.com.

[Dark Angel 58]

Chrome en Edge lijken niet affected, net getest via https://safarileaks.com.

Omdat ze niet safari zijn?

[Anonymoussaurus]

Dat betekent het niet per se. Er staat wel dat je het kan testen op Safari 15 op MacOS, maar dat betekent nog niet per definitie of er enkel een check wordt gedaan op basis van of je Safari 15 draait of niet. Zou wel een hele eenvoudige check zijn. Source code staat hier: https://github.com/finger...dexeddb-safari-leaks-demo

[Maurits van Baerle]

Volgens mij is Blink strikt genomen een fork van WebCore en niet van WebKit (de combinatie van WebCore en JavaScriptCore).

Chrome en Edge maken geen gebruik van JavaScriptCore en daar lijkt het probleem op het eerste gezicht in te zitten omdat er een JavaScript API gebruikt wordt om de IndexedDB functionaliteit aan te spreken en daar wordt er niet op SameOrigin gecontroleerd.

[kraanwagen]

Ik zou in ieder geval regelmatig Instellingen>Safari>wis geschiedenis en websitedata aanklikken als je Safari blijft gebruiken.

[Dark Angel 58]

Is dat genoeg?

[kraanwagen]

Weet niet zeker: toen ik via https://safarileaks.com/ testte zag ik toch geleakte websites…

[HADES2001]

Nee, enige "workaround" is javascript standaard uit zetten maar succes om dan nog normaal een site te openen. Beste is voor nu een andere webbrowser te gebruiken als je op Mac zit, iphones/ipads kan je vergeten die moeten patch afwachten
#EDIT even verduidelijkt alleen voor je mac andere browser

[Reactie gewijzigd door HADES2001 op 22 juli 2024 15:59]

[NielsKersic]

Ik vind het bizar dat Apple nog steeds in staat is om andere browser engines te weren van iOS en iPad OS. Als je verplicht dat Chrome, Firefox, Brave en alle andere browsers op iOS in principe allemaal een reskin zijn van Safari, dan vind ik dat je een plicht hebt naar je gebruikers om ervoor te zorgen dat Safari zo goed mogelijk is, of op z'n minst veilig en functioneel.

[Maurits van Baerle]

Wat Apple doet is vereisen dat apps alle code die ze uitvoeren ook in de App Store plaatsen en niet achteraf vanaf het internet inladen. Dat maakt het mogelijk om alle code die gebruikt wordt te controleren (sowieso met Static Code Analysis, automatische malware scans en er zal soms ook wel wat handwerk bij komen kijken) voor een app ter download kan worden aangeboden aan gebruikers.

Browsers zijn eigenlijk een volledig applicatieplatform die nou juist bedoeld zijn om code vanaf het internet in te laden en daarna uit te voeren. Je kunt dus prima een alternatieve browser aanbieden (en daar zijn er dus ook redelijk wat van) maar je kunt niet die onderdelen meeleveren die verantwoordelijk zijn voor het uitvoeren van vreemde code. Dat betekent dat browserdevelopers die onderdelen niet kunnen meeleveren en als alternatief moeten leunen op WebCore en JavaScriptCore die standaard op het platform aanwezig zijn.

Nou zou je kunnen zeggen, waarom maakt Apple geen uitzondering voor Google, Mozilla, Microsoft, Opera etc? Ik vermoed dat het probleem is waar je de grens legt. Als dan nummer vijf bij Apple aanklopt en zegt ook hun eigen code execution platform te willen leveren dan moet Apple uitleggen waarom die vier wel mogen en nummer vijf niet. En als je nummer vijf toe laat, waarom dan niet ook nummer 73? Dan open je alsnog de deur voor allerlei trojans met schimmige apps die zichzelf presenteren als "browser" maar eigenlijk gewoon na een maand een hele sloot malware downloaden en uitvoeren.

Op zich is het ene dus het logisch gevolg van het andere. Ik zie daar zo ook niet een andere oplossing voor. Maar, ik ben het met je eens dat dat dus ook betekent dat Apple een bovengemiddelde verantwoordelijkheid heeft om goed met dit soort zaken om te gaan. Code zonder bugs bestaat niet dus de werkelijke maatstaf zou moeten zijn hoe snel ze dit soort problemen oplossen. De teller voor dit probleem staat nu op precies 50 dagen.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 15:59]

[R4gnax]

Een oplossing daarvoor zou kunnen zijn om daar wel degelijk discretionair mee om te gaan.
"Maar waarom ik niet en zij wel!" is geen geldig argument inzake bijv. anti-competitie / monopolie wetgeving, als de grondslag is: "zij hebben aangetoond betrouwbaar genoeg te zijn dat dit geen significant risico voor het platform vormt."

De echte reden is natuurlijk niet dat Apple alternatieve execution platforms wil weren omdat ze onveilig zouden zijn; maar simpelweg omdat je daarmee een distributie-keten op kunt zetten die buiten hun App Store om gaat waardoor ze hun vette 15-30% commissie mislopen.

Zelfde reden dat ze Safari op iOS altijd neeee-----t aan voldoende vleugellam houden dat web-based applicaties het af moeten leggen tegen native applicaties.

[Daoka]

"zij hebben aangetoond betrouwbaar genoeg te zijn dat dit geen significant risico voor het platform vormt."

1: Is dit ook niet een vorm van concurrentie dwarsbomen? Uiteindelijk een paar bedrijven dus meer mogelijkheden dan de andere.

2: wat is de definitie van betrouwbaar? Elke browser heeft bugs en veiligheidsproblemen. Is dit dan nog steeds betrouwbaar? Google playstore heeft trouwens ook wel eens met betrouwbaarheid gewerkt. Nieuwe apps werden een aantal keer gecheckt en daarna automatisch goedgekeurd. Sommige apps maakte hier dus misbruik van. Eerst even een aantal keer goed gekeurd worden met een app die geen misbruik maakte en daarna ineens dat er dus troep ingestopt werd om stiekem bepaalde dingen te doen die ze dus niet mochten doen. Ook is de vraag hoe "betrouwbaar" zijn Google, Mozilla, Microsoft, Opera? Er zijn genoeg situaties geweest waar ieder geval Google en Microsoft toch discutabele dingen gedaan heeft / aan de rand van de wet zat of zelfs er een klein beetje over ging / dingen zo aangepast heeft dat het erg in hun voordeel werkt. Technisch gezien zou dit ook niet onder betrouwbaar moeten vallen. Er zijn genoeg Tweakers die deze bedrijven proberen te vermijden en dat is niet omdat ze de logo niet mooi vinden.

Dus nogmaals wat is betrouwbaar? Waar ligt de grens van vertrouwen? Het zal inderdaad wel zijn dat ze de commissie willen hebben. Maar dat betekent niet dat de rest ook niet van toepassing is. En voordat ik als Apple fanboy wordt neergezet: Ik heb geen een Apple product in bezit. Ik heb gewoon Windows en Android telefoon.

[Aaargh!]

Zullen we anders eens ophouden met dit soort ongein in webbrowsers bouwen ? Een webbrowser moet gewoon beperkt blijven tot het lezen van tekstdocumenten. Als je een app wil bouwen doe je dit maar native.

[R4gnax]

Zullen we anders eens ophouden met dit soort ongein in webbrowsers bouwen ? Een webbrowser moet gewoon beperkt blijven tot het lezen van tekstdocumenten. Als je een app wil bouwen doe je dit maar native.

Ik kan je ook van dit soort side-channel leaks geven die met CSS geschreven zijn, zeker in het verleden. (Wie kent er :visited nog?)

Ook maar afschaffen dan?

Of waarom daar stoppen, want malware kan ook direct in HTML. Bijv. bepaalde unicode-character sequences die tot een exploiteerbare crash komen waarmee code uitgevoerd kan worden. (Wat heel poignant dacht ik ook een iOS probleem was, vele jaren terug.)
Stekker dan maar uit het hele WWW trekken?

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:59]

[Aaargh!]

Nee, iets als :visited is core functionaliteit. Beveiligingsproblemen zullen er altijd zijn, maar dat wil niet zeggen dat je het mogelijke aanvalsoppervlak zo groot mogelijk moet maken, integendeel.

Wat er nu gebeurt in browsers is een gevalletje inner-platform effect. De browser wordt net zo lang uitgebreid tot het alle mogelijkheden heeft van het onderliggende OS. Maar wat is dan nog het nut van een browser ? Dan kan je net zo goed de tussenpersoon weglaten direct alles op het onderliggende OS draaien.

[Keypunchie]

Dit is best wel heftige impact, als ik het zo inschat. Overigens is het van een website die gebruik maakt van dit lek grove schending van de privacy, dus de meeste legitieme sites zullen dit niet doen.

Maar ranzige ad-tech bedrijven wellicht wel.

Wat me licht verbaasd is dat dit 28 november gemeld is, maar nu al openbaar. Dit zit best wel diep in Safari, daar kunnen ze Apple toch wel iets meer tijd geven om het te fixen?

60 dagen lijkt me niet onredelijk, zeker gegeven de kerstperiode.

[Sitelabs]

Overigens is het van een website die gebruik maakt van dit lek grove schending van de privacy, dus de meeste legitieme sites zullen dit niet doen.

Of plug-in bouwers van een van de vele populaire (gratis) CMS'en middels een fijne "gratis" plug-in.

[SoloH]

Hebben die niet zowiezo toegang tot al je webpagina’s die je bezoekt?

[lilmonkey]

Sowieso*, en nee. Het gaat niet over browser-plug-ins.

[joneboon]

in incognito mode werkt dit ook zo?

[AmotaX]

Ja, maar dan alleen voor websites die in hetzelfde tabblad bezocht zijn. Iets meer geïsoleerd dus.

[Verwijderd]

Is dit niet mogelijk in andere browsers dan?
Of word ergens op de achtergrond bij andere browsers dan safari het domein opgeslagen of de inhoud van de db versleuteld?

EDIT:
Filmpje gekeken, same-origin dus.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:59]

[AmotaX]

In de Safari 15.2 update (voor macOS Big Sur) van vandaag is het helaas nog niet gefixt. Heb de demo website (https://safarileaks.com) getest in 15.1 en daarna 15.2.