WebKit espone IP e DNS anche con proxy e iCloud Private Relay

Safari e gran parte dei browser disponibili su iPhone e iPad affidano il caricamento delle pagine a WebKit, il motore di rendering sviluppato da Apple. È il componente che interpreta HTML, CSS e JavaScript, gestisce molte comunicazioni di rete e permette anche alle applicazioni di mostrare contenuti web attraverso le viste integrate nel sistema operativo.

Una ricerca elaborata da Talal Haj Bakry e Tommy Mysk mostra però che non tutte le richieste generate da WebKit seguono necessariamente il percorso di rete scelto dal browser. Alcune funzioni possono ignorare il proxy configurato dall’applicazione e collegarsi direttamente a Internet, rivelando il vero indirizzo IP pubblico dell’utente oppure informazioni sul resolver DNS utilizzato.

Il comportamento riguarda anche Safari quando la navigazione risulta protetta da iCloud Private Relay, il servizio incluso in iCloud+ che nasconde l’indirizzo IP durante il normale accesso ai siti. La pagina può apparire correttamente instradata attraverso i relay di Apple, mentre una richiesta secondaria parte dalla connessione reale del dispositivo.

Perché un proxy configurato in WebKit non protegge ogni connessione

I ricercatori hanno individuato tre percorsi distinti: il precaricamento dei nomi DNS, una verifica utilizzata dalle passkey sui domini correlati e le connessioni WebTransport basate su QUIC. Non si tratta di tre varianti dello stesso attacco, ma di funzioni differenti che condividono un problema di fondo: usano componenti di rete che non ereditano sempre le impostazioni applicate alla normale sessione del browser.

In pratica, il caricamento principale della pagina continua a passare attraverso il proxy o Private Relay; alcune operazioni collaterali possono invece aggirare la protezione. Un normale sito di controllo dell’IP pubblico potrebbe non segnalare alcuna anomalia, nonostante la pagina abbia già stabilito un secondo collegamento fuori dal canale protetto.

La configurazione non equivale però a una VPN. Un proxy applicativo protegge soltanto le comunicazioni che passano dalla sessione di rete a cui risulta associato. Una VPN interviene infatti a un livello più basso: modifica l’instradamento IP del dispositivo o di determinate applicazioni. Perciò, una richiesta che sfuggisse alla sessione WebKit transiterebbe comunque per il tunnel VPN.

Tre funzioni di WebKit possono aggirare il proxy

Come anticipato nell’introduzione, i ricercatori hanno individuato tre funzioni capaci di generare traffico fuori dal proxy usato dal browser.

La prima è il DNS prefetching: una pagina può chiedere a WebKit di cercare in anticipo l’indirizzo IP associato a un dominio, così da velocizzare un collegamento successivo. Su iOS tale richiesta può raggiungere direttamente il resolver DNS configurato sul dispositivo; il sito non vede necessariamente l’IP dell’utente, ma può ricavare informazioni sul provider, sulla posizione approssimativa e sulla rete utilizzata.

Il secondo caso riguarda le passkey condivise tra più domini della stessa organizzazione. Per controllare che la condivisione sia autorizzata, il sistema scarica uno specifico file dal dominio interessato; su iOS la verifica passa però attraverso il servizio che gestisce le credenziali, senza rispettare il proxy del browser, e il server può quindi ricevere l’indirizzo IP pubblico. Non si parla di furto delle passkey: a uscire dal percorso protetto è soltanto la richiesta di controllo.

La terza tecnica sfrutta WebTransport, una tecnologia destinata alle applicazioni Web che richiedono comunicazioni rapide e interattive. Nei test, WebKit ha aperto una connessione diretta verso il server indicato dalla pagina, rivelando subito l’IP reale del dispositivo.

In tutti e tre i casi il problema è lo stesso: alcune operazioni secondarie non ereditano il proxy applicato al normale caricamento dei siti e possono quindi vanificare, almeno in parte, la protezione attesa dall’utente.

Perché iCloud Private Relay non blocca le richieste

Private Relay protegge soprattutto il traffico web di Safari. Il servizio divide le informazioni tra due relay: il primo, gestito da Apple, conosce l’indirizzo IP dell’utente ma non il sito visitato; il secondo conosce il dominio di destinazione e assegna un indirizzo temporaneo, ma non vede l’IP originale.

Il meccanismo riduce la possibilità che un singolo operatore conosca contemporaneamente identità e destinazione: non rappresenta però una VPN completa e non intercetta ogni comunicazione generata dal dispositivo.

Proxy del browser e VPN non offrono la stessa protezione

Lo studio appena pubblicato mette in evidenza che alcune API possono uscire dal percorso previsto.

Chi necessita di una protezione più ampia dovrebbe usare una VPN affidabile, verificando che non esistano eccezioni per determinate applicazioni. Una VPN non assicura comunque anonimato assoluto: cookie, fingerprinting, account autenticati, identificatori locali e abitudini di navigazione possono collegare le sessioni anche senza conoscere l’IP originale.

Un browser non attiva un solo canale di comunicazione: usa processi di rete, servizi per le credenziali, resolver DNS e protocolli specializzati. Applicare un proxy al caricamento delle pagine non basta: ogni funzione capace di generare traffico deve rispettare le stesse regole, altrimenti la protezione resta incompleta proprio nei punti meno visibili all’utente.