ACyberNinjaDe onthulde truc waarbij Safari omgaat met aangepaste cursors op macOS heeft de zorgen over adresbalk-spoofing opnieuw aangewakkerd.
Door dit probleem kunnen aanvallers vervalste tekst, zoals ‘icloud.com’, over de adresbalk van Safari heen leggen, waardoor een misleidend beeld ontstaat dat phishing-pogingen kan ondersteunen.
Het rapport werd voor het eerst openbaar gemaakt op 28 augustus 2025 door een onafhankelijke onderzoeker genaamd “RenwaX23”, die ook eenproof-of-concept op GitHuben eendemonstratievideo over X. De truc hangt af van het feit dat Safari er niet in slaagt strikte controles van de cursorgrenzen af te dwingen, die door sommige onderzoekers de “Lijn van de dood”, die browsers zoals Chrome en Firefox gebruiken om te voorkomen dat pagina-inhoud visueel interfereert met vertrouwde UI-elementen zoals de adresbalk.
Door een extra grote aangepaste cursorafbeelding (128 x 128 pixels) te maken, kunnen aanvallers tekst of afbeeldingen visueel over delen van de gebruikersinterface van Safari heen plaatsen. Als u bijvoorbeeld met de muis over een knop 'Inloggen bij iCloud' beweegt, kan er een cursorafbeelding worden geactiveerd die 'icloud.com' op dezelfde positie weergeeft als de adresbalk van Safari, ook al bevindt de gebruiker zich nog steeds op een mogelijk kwaadaardige site.
Dit probleem is getest en het werkt in Safari versie 18.4 (build 20621.1.15.11.5) op macOS 15.4 Bèta (24E5238a). Sommige gebruikers op sociale media melden echter een gedeeltelijke beperking in Safari 18.6, waarbij de cursoroverlapping verminderd of geblokkeerd lijkt, afhankelijk van interfacevariaties zoals de aanwezigheid van bladwijzers of of Safari zich in de modus voor privé browsen bevindt.
Een oud probleem dat opnieuw de kop opsteekt?
De cursorgebaseerde spoofing-methode is niet geheel nieuw. Een fout uit 2009, bijgehouden alsCVE-2009-1710, beschreef een soortgelijk probleem in oudere versies van WebKit, waar aangepaste cursors in combinatie met gemanipuleerde CSS-hotspots het vervalsen van browser-UI-elementen mogelijk maakten, inclusief de hostnaam en beveiligingsindicatoren. Er wordt gespeculeerd dat het huidige gedrag in Safari mogelijk een regressie is van die oudere bug.
Ondanks het duidelijke phishing-potentieel heeft Apple geweigerd dit gedrag als een beveiligingsprobleem te classificeren. Het rapport werd op 5 mei 2025 bij Apple ingediend, later die maand erkend en op 7 augustus officieel afgesloten met de verklaring dat het niet voldoet aan de criteria van het bedrijf voor een kwetsbaarheid. Dit heeft geleid tot frustratie bij delen van de beveiligingsgemeenschap, waarbij sommigen beweren dat moderne phishing-aanvallen vaak berusten op subtiele, visuele trucs in plaats van op technische exploits, en dat de gebruikersinterface van Safari dergelijk visueel bedrog zou moeten voorkomen.
Aanbevolen lees:5 aangepaste Cursor Chrome-extensies om van die saaie muiscursor af te komen
Betwiste status
De onthulling heeft de gemeenschap verdeeld. Sommigen beweren dat dit een risicovolle UI-misleidingsfout is die het vertrouwen van de gebruiker in de visuele beveiligingssignalen van de browser ondermijnt. Anderen zijn van mening dat het probleem te indirect is om als een echte kwetsbaarheid te worden beschouwd, vooral omdat Safari geen JavaScript-gestuurde manipulatie van de adresbalk zelf toestaat, en cursorgebaseerde spoofing geen invloed heeft op de browserlogica of de mechanismen voor het automatisch aanvullen van inloggegevens.
Er is ook op gewezen dat de functies voor wachtwoordbeheer en automatisch aanvullen van Safari niet worden geactiveerd op de vervalste elementen, wat enige bescherming biedt tegen directe diefstal van inloggegevens.
Hoewel dit geen kwetsbaarheid in de traditionele zin is, aangezien er geen code-uitvoering of ontsnapping uit de beveiligingssandbox plaatsvindt, vormt het wel een potentiële phishing-vector die afhankelijk is van menselijke fouten en vertrouwen in de adresbalk van Safari. Daarom moeten Safari-gebruikers zich bewust zijn van deze potentiële bedreiging. Aanvallers zouden deze visuele parodie kunnen combineren met social engineering en trucs buiten het platform (zoals nep-e-mails) om gebruikers ervan te overtuigen inloggegevens in te voeren op een vergelijkbare site. De beste aanpak zou het gebruik van wachtwoordmanagers zijn die afhankelijk zijn van domeinmatching voor het automatisch invullen van inloggegevens, die niet worden beïnvloed door dit soort visuele trucs.