🛡️ Executive Summary
- DNS prefetching, WebAuthn Related Origin Requests e WebTransport possono aggirare i proxy configurati nelle applicazioni basate su WebKit.
- I siti possono rilevare DNS o indirizzo IP reale anche quando Safari utilizza iCloud Private Relay.
- Psylo 1.3.1 blocca le tre funzioni per impostazione predefinita, mentre le VPN di sistema non risultano coinvolte.
Tre funzioni di WebKit possono aggirare i proxy configurati dai browser su iPhone, iPad e Mac, esponendo direttamente i server DNS o l’indirizzo IP reale dell’utente. La ricerca riguarda DNS prefetching, WebAuthn Related Origin Requests e WebTransport, tecnologie legittime che generano connessioni fuori dal normale percorso di rete della pagina. Il problema interessa anche iCloud Private Relay, il servizio Apple che inoltra il traffico di Safari attraverso due relay separati. Le VPN non risultano esposte alla stessa debolezza perché intercettano il traffico dell’intero dispositivo a livello di sistema, anziché affidarsi esclusivamente alla configurazione proxy di WebKit.
Cosa leggere
Tre funzioni WebKit aggirano il proxy del browser
I browser basati su WebKit possono utilizzare l’interfaccia WKWebsiteDataStore.proxyConfigurations per instradare le connessioni web attraverso un server proxy. La funzione, introdotta con iOS 17 e macOS 14, viene utilizzata dalle applicazioni che promettono navigazione isolata o anonimizzata, compresi browser compatibili con Tor e prodotti come Psylo. In condizioni normali, il sito visitato dovrebbe vedere soltanto l’indirizzo del proxy.
La ricerca pubblicata da Talal Haj Bakry e Tommy Mysk dimostra però che alcune operazioni vengono eseguite da componenti che non ricevono la configurazione proxy della sessione. Il traffico parte quindi direttamente dalla rete del dispositivo e permette al server controllato dal sito di collegare la visita all’indirizzo IP reale. Il problema non richiede l’installazione di malware o l’interazione dell’utente: una pagina può includere gli elementi necessari e osservare le richieste generate automaticamente. La scoperta arriva in un momento nel quale Apple ha appena corretto 194 vulnerabilità in iOS, macOS, Safari e negli altri sistemi operativi, ma i leak descritti da Mysk non risultano ancora associati a un bollettino di sicurezza o a identificativi CVE.
DNS prefetching rivela la rete usata dal dispositivo
Il primo leak sfrutta il DNS prefetching, funzione progettata per velocizzare l’apertura dei collegamenti. Una pagina può inserire il tag <link rel="dns-prefetch"> e chiedere al browser di risolvere in anticipo un dominio che potrebbe servire successivamente. WebKit esegue però la risoluzione attraverso il normale percorso DNS del dispositivo, senza utilizzare il proxy configurato dal browser. Un sito può generare un sottodominio unico per ciascun visitatore e controllare il proprio server DNS autoritativo: quando riceve la richiesta, rileva il resolver e la rete reale da cui proviene.
La tecnica non espone necessariamente l’indirizzo assegnato direttamente al dispositivo, perché possono intervenire resolver del provider o servizi DNS esterni, ma permette di aggirare la separazione promessa dal proxy e ottenere informazioni utili per localizzazione e correlazione delle sessioni. Il comportamento interessa anche Safari con Private Relay attivo, poiché queste richieste DNS speculative non entrano nel percorso protetto dal servizio. Il rischio è concettualmente vicino a quello analizzato nello studio sulle VPN Android gratuite che perdevano traffico e dati nonostante le promesse di privacy: la presenza di un proxy o di un indicatore di protezione non garantisce che ogni sottosistema utilizzi davvero lo stesso canale.
WebAuthn può contattare un dominio senza mostrare finestre
La seconda tecnica coinvolge WebAuthn Related Origin Requests, meccanismo che permette a più domini appartenenti alla stessa organizzazione di condividere una passkey. Quando il dominio richiesto dalla credenziale è diverso dall’origine della pagina, il sistema deve recuperare un file di verifica dal percorso /.well-known/webauthn del relying party. La richiesta non viene eseguita attraverso il normale stack di rete del browser, ma dal servizio credenziali del sistema operativo, che non conosce il proxy impostato dall’applicazione. Una pagina può indicare un dominio controllato dall’attaccante e provocare il collegamento diretto usando la modalità condizionale, senza mostrare una finestra WebAuthn o chiedere all’utente di selezionare una passkey. Il server riceve così l’indirizzo IP reale anche quando la navigazione principale passa attraverso un proxy o Private Relay. La tecnica non sottrae credenziali e non compromette la crittografia delle passkey, ma utilizza una fase di validazione come canale laterale per identificare la rete del visitatore. Il caso mostra nuovamente come la sicurezza di WebAuthn dipenda anche dai servizi esterni al browser, tema già emerso con gli attacchi Pass-ta-key contro le passkey sincronizzate da Google Password Manager.
WebTransport apre una connessione HTTP/3 diretta
La terza falla logica riguarda WebTransport, tecnologia per comunicazioni a bassa latenza basata principalmente su HTTP/3 e QUIC. Quando una pagina crea una nuova sessione WebTransport, WebKit stabilisce il collegamento usando parametri di rete propri e non eredita il proxy configurato tramite WKWebsiteDataStore. Il server remoto vede quindi l’indirizzo IP reale del dispositivo. Anche iCloud Private Relay viene aggirato perché la connessione viene costruita fuori dal percorso standard del traffico Safari protetto dal servizio. WebTransport è disponibile pubblicamente da iOS 26.4, mentre le Related Origin Requests sono presenti da iOS 18 e il DNS prefetching ha iniziato a operare su iOS dalla versione 26. La combinazione significa che il livello di esposizione cambia in base alla versione del sistema, alle funzioni attivate dal sito e al browser utilizzato. Una precedente vulnerabilità come iLeakage permetteva di sottrarre email e password attraverso l’esecuzione speculativa in Safari; in questo caso non vengono letti contenuti della pagina, ma viene violata la separazione tra l’identità di rete reale e quella mostrata dal proxy.
Private Relay non equivale a una VPN di sistema
Apple descrive iCloud Private Relay come un sistema che protegge la navigazione di Safari separando l’indirizzo IP dell’utente dalla destinazione visitata: il primo relay conosce chi si collega ma non il sito finale, mentre il secondo conosce il sito ma non l’identità originaria. Le tre funzioni individuate da Mysk operano però al di fuori di questo percorso e possono contattare direttamente un server scelto dalla pagina. Private Relay continua quindi a proteggere il traffico ordinario supportato, ma non deve essere interpretato come un tunnel completo applicato a ogni connessione del dispositivo. Le VPN non sono interessate dalla specifica ricerca perché lavorano a livello di sistema e intercettano anche le richieste generate dai servizi WebAuthn o dalle connessioni QUIC. Psylo ha corretto il problema nella versione 1.3.1, bloccando i suggerimenti DNS prefetch e disabilitando WebAuthn e WebTransport per impostazione predefinita, con la possibilità di riattivarli per singolo ambiente. Per Safari e gli altri browser WebKit, una correzione completa richiede invece che Apple faccia rispettare la configurazione proxy anche ai componenti che oggi creano connessioni esterne indipendenti.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
