Le difese contro lo spoofing IDN di Chromium non rilevano domini sosia convincenti
Le difese contro lo spoofing IDN di Chromium non hanno rilevato 20 domini sosia registrati, nonostante anni di salvaguardie progettate per rendere evidenti gli indirizzi Unicode ingannevoli. Un dominio proof-of-concept somigliava molto a apple.com pur apparendo in Unicode leggibile, anziché nel vistoso formato Punycode che inizia con xn--.
La scoperta non significa che gli aggressori abbiano registrato il dominio di Apple o compromesso la sua infrastruttura. I ricercatori di Have I Been Squatted, o HIBS, hanno registrato un dominio diverso i cui caratteri cirillici assomigliano alle lettere latine di “apple”. I loro test mostrano come caratteri selezionati con cura possano superare le regole di visualizzazione di Chromium e le sue difese separate in fase di navigazione.
Il risultato riporta in primo piano un conflitto che i browser gestiscono da quando i nomi di dominio internazionalizzati sono entrati nell'uso diffuso. Il web necessita di indirizzi scritti nelle lingue effettivamente usate dalle persone. Tuttavia, la stessa varietà di caratteri offre agli aggressori più modi per imitare marchi affidabili, provider di identità e servizi di pagamento.
Chromium applica già uno dei sistemi di difesa più dettagliati del settore. Verifica gli script, le combinazioni di caratteri sospette, i domini noti e la cronologia di navigazione. I nuovi esempi non annullano queste protezioni. Rivelano come alcuni caratteri possano sfuggire a livelli che prendono ciascuno decisioni leggermente diverse.
I ricercatori hanno individuato un nuovo caso limite nello spoofing IDN di Chromium
Il cambiamento importante non è il ritorno di un attacco dimenticato, ma la prova che gli attuali controlli di Chromium consentono ancora nuove varianti convincenti.
I ricercatori HIBS Ian Muscat e Leanne Briffa hanno pubblicato la loro analisi il 3 ottobre 2026. Hanno esaminato se un dominio internazionalizzato potesse somigliare a un famoso indirizzo in alfabeto latino pur continuando ad apparire in Unicode nei browser basati su Chromium.
Un nome di dominio internazionalizzato, o IDN, contiene caratteri oltre l'alfabeto inglese di base. Le applicazioni traducono tali caratteri in una rappresentazione compatibile con ASCII chiamata Punycode prima di effettuare una richiesta DNS. Un dominio che inizia con xn-- non è quindi automaticamente pericoloso. È una forma codificata necessaria per l'attuale Domain Name System.
I browser spesso riconvertono quella forma codificata in Unicode leggibile per la visualizzazione. Questo supporta indirizzi legittimi in arabo, cirillico, cinese e molti altri sistemi di scrittura. Il problema di sicurezza emerge quando caratteri diversi condividono forme quasi identiche.
I ricercatori si sono concentrati su аррӏө.com, un dominio che può somigliare a apple.com nei font comuni. Le sue lettere sono cirilliche, inclusi caratteri con la forma di una “a” latina, due caratteri “p” e una “l”. Il carattere cirillico finale, ө, somiglia a una “e” arrotondata quando viene visualizzato nelle dimensioni della barra degli indirizzi.
L'indirizzo non è apple.com. La sua forma codificata è xn--80a6aa68c8d.com e il DNS lo considera un nome distinto. Tuttavia, la versione leggibile può creare l'impressione visiva che un visitatore abbia raggiunto il dominio di Apple.
HIBS ha registrato quel dominio e altri 19 sosia come proof of concept. L'elenco imitava nomi associati a OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike e altre organizzazioni riconoscibili.
La ricerca IDN originale afferma che Chrome 154 mostrava il sosia di Apple in Unicode con un certificato valido. Ha inoltre superato i controlli di navigazione valutati dai ricercatori senza generare un avviso sui sosia.
Un certificato valido non dimostra che un dominio appartenga al marchio che sembra rappresentare. Conferma che il browser ha stabilito una connessione crittografata con il dominio indicato in quel certificato. Gli aggressori possono ottenere certificati per domini che controllano legittimamente, compresi quelli ingannevoli.
Gli esempi erano registrazioni controllate, non prove di una campagna rivolta ai clienti di tutte le aziende nominate. Questa distinzione è importante perché uno spoof tecnicamente praticabile non equivale automaticamente a un'operazione di phishing attiva.
Tuttavia, la praticabilità tecnica è il punto centrale della scoperta. Un dominio ingannevole può supportare un sito web reale, HTTPS, email, reindirizzamenti e altri normali servizi internet. Gli aggressori potrebbero quindi combinare la somiglianza visiva con un annuncio di ricerca, un'email fraudolenta, un codice QR, un link abbreviato o una pagina di accesso copiata.
La ricerca è apparsa in una più ampia copertura il 18 ottobre, quando un'indagine sul typosquatting ha descritto nel dettaglio come le sostituzioni cirilliche abbiano superato le regole di Chromium. La tempistica rinnova l'attenzione sulle difese che molti utenti non vedono mai, a meno che il browser non rilevi qualcosa di sospetto.
Questo crea la tensione centrale dell'articolo. Chromium deve distinguere le sostituzioni visive ingannevoli dalle parole legittime usate da milioni di persone. Una regola abbastanza ampia da cogliere ogni somiglianza renderebbe anche gli ordinari indirizzi internazionali più difficili da leggere e considerare affidabili.
Come i sosia Unicode di Chromium superano più controlli
Il sosia di Apple supera i controlli perché nessuna singola regola di Chromium valuta l'impressione visiva completa che raggiunge l'utente.
Chromium non si limita a chiedere se un dominio contiene Unicode. Elabora gli IDN attraverso diversi test prima di decidere se mostrare caratteri leggibili o l'etichetta Punycode sottostante.
Il primo livello principale usa il controllo anti-spoofing di International Components for Unicode. Chromium lo configura al livello “Highly Restrictive”, che limita le combinazioni sospette di sistemi di scrittura.
Un'etichetta mista contenente un carattere cirillico tra lettere latine normalmente non supera questo test. Sostituire solo la prima “a” in apple.com, per esempio, fa sì che Chromium visualizzi xn--pple-43d.com. L'indirizzo codificato ha molte meno probabilità di essere scambiato per l'originale.
Il nuovo sosia di Apple evita questo risultato perché ogni lettera prima di .com è cirillica. È un'etichetta a singolo script, non una mescolanza evidente di caratteri latini e cirillici.
Chromium mantiene anche un insieme di caratteri consentiti. Esclude vari blocchi Unicode e singoli punti di codice associati a visualizzazioni rischiose o confuse. I caratteri in аррӏө.com restano idonei, in parte perché sono lettere legittime usate in lingue reali.
Seguono diversi controlli mirati. Chromium limita thorn ed eth islandesi al di fuori dei domini nazionali pertinenti. Limita la schwa azera e applica una regola specifica al punto mediano catalano. Nessuna di queste restrizioni riguarda la sequenza cirillica del proof of concept.
La difesa più rilevante è il controllo dei confondibili dell'intero script di Chromium. Cerca etichette scritte interamente con caratteri cirillici che assomigliano tutti a caratteri latini.
Chromium ha introdotto questa protezione dopo una dimostrazione del 2017 ampiamente discussa. Il ricercatore di sicurezza Xudong Zheng aveva registrato una versione interamente cirillica di apple.com che i browser visualizzavano come una copia visiva molto simile dell'indirizzo reale.
Chromium ha risposto con Chrome 58. Il suo controllo dell'intero script identifica un insieme di 29 caratteri cirillici che somigliano a caratteri latini. Quando ogni lettera in un'etichetta a singolo script appartiene a quell'insieme, Chromium può visualizzare il dominio in Punycode.
Questa difesa rileva la versione del 2017. Non rileva la nuova variante perché ө non rientra tra i 29 caratteri elencati. Un solo carattere esterno all'insieme fa venir meno la condizione relativa all'intero script, anche se l'etichetta completa continua a somigliare a “apple”.
Il browser deve consentire quel carattere da qualche parte perché non è un simbolo inventato. Il cirillico ө è usato in kazako, mongolo, tataro e altre lingue. Bloccarlo ovunque imporrebbe un costo di usabilità ai parlanti legittimi.
Chromium utilizza poi un confronto tramite skeleton per i domini protetti. Uno skeleton riduce i caratteri visivamente correlati a una rappresentazione normalizzata che il software può confrontare con nomi noti.
Il processo è utile ma non può riprodurre perfettamente la visione umana. In questo caso, la barra attraverso ө sopravvive alla normalizzazione. Lo skeleton risultante termina con una forma basata su “o” più un segno combinante, anziché sulla prevista “e” latina.
Questa differenza impedisce una corrispondenza esatta con lo skeleton di apple.com. Un piccolo segno basta a modificare il risultato computazionale, anche quando quel segno diventa difficile da vedere in un'interfaccia browser compatta.
Gli esempi in alfabeto latino evidenziano una debolezza correlata. I ricercatori hanno usato caratteri come ƙ, una lettera latina con uncino, per imitare la “k” in nomi tra cui Okta e Nike. Chromium non può applicare un ampio avviso relativo all'intero script ai caratteri latini perché i domini latini accentati sono comuni e legittimi.
Chromium assegna invece una protezione skeleton più forte a un elenco incluso di domini importanti. HIBS ha trovato 8.462 nomi in tale elenco, inclusi 836 in un gruppo a priorità più alta. Tuttavia, un carattere che conserva un segno aggiuntivo può impedire una corrispondenza skeleton esatta.
Le linee guida di visualizzazione di Chromium riconoscono questo equilibrio di fondo. Chrome mostra il Punycode quando le sue regole di visualizzazione IDN identificano un rischio di omografia, ma evita di trattare ogni indirizzo non ASCII come ostile.
Questo equilibrio rende lo spoofing IDN di Chromium un problema di classificazione, piuttosto che un semplice problema di blacklist. Ogni nuova regola deve intercettare somiglianze dannose senza trasformare i nomi internazionali legittimi in stringhe codificate illeggibili.
Gli avvisi del browser forniscono una seconda difesa, con limiti
Un dominio visualizzato in Unicode affronta comunque controlli di navigazione, ma tali controlli dipendono da confronti esatti, lunghezza del nome e cronologia del visitatore.
Chromium separa la visualizzazione dell'indirizzo dalla protezione al momento della navigazione. Il primo sistema determina l'aspetto di un hostname nella barra degli indirizzi. Il secondo può interrompere o annotare una visita dopo che l'utente ha effettuato la navigazione.
Il componente di navigazione per i sosia di Chromium confronta un indirizzo visitato con domini popolari e siti visitati regolarmente dall'utente. A seconda della corrispondenza, Chrome può mostrare un interstitial a pagina intera o un Safety Tip meno invasivo.
Il progetto degli avvisi sui sosia descrive questi controlli come un livello aggiuntivo accanto a Google Safe Browsing. La popolarità e il precedente coinvolgimento di un utente offrono al browser punti di riferimento per identificare alternative sospette.
HIBS riferisce che una corrispondenza skeleton esatta con uno degli 836 domini a massima priorità produce un interstitial. Una corrispondenza esatta con un altro dominio incluso può produrre un Safety Tip.
Il browser considera anche i siti che l'utente visita con frequenza sufficiente. Se un nuovo indirizzo assomiglia esattamente a uno di questi siti abitualmente visitati, Chromium può bloccare la navigazione e chiedere se il visitatore intendesse aprire il dominio noto.
Le corrispondenze quasi esatte ricevono un trattamento più ristretto. Chromium può rilevare uno skeleton che differisce per un carattere inserito, rimosso o sostituito. Può inoltre riconoscere uno scambio tra caratteri adiacenti.
Questi confronti non si applicano in modo uniforme. Secondo la ricerca, il test di quasi corrispondenza salta le etichette di destinazione più brevi di cinque caratteri prima del dominio di primo livello. Questo è rilevante per i marchi con nomi compatti.
Il sosia di Okta che usa ƙ differisce di una modifica dal nome reale, ma “okta” ha quattro caratteri. I ricercatori affermano che ciò lo rende troppo breve per il controllo di quasi corrispondenza pertinente.
L’esempio Apple fallisce per una ragione diversa. Il suo scheletro è a due modifiche di distanza da apple.com perché ө si normalizza in una “o” più una barra mantenuta. Il confronto per quasi-corrispondenza consente una sola modifica.
Di conseguenza, il dominio testato è stato visualizzato in Unicode e caricato senza un avviso di imitazione. HIBS afferma che ciò è rimasto vero anche per chi visitava regolarmente l’autentico sito web di Apple.
Questi risultati non devono essere interpretati come un audit completo di tutte le protezioni che circondano una visita. Safe Browsing, feed di threat intelligence, software endpoint, filtraggio DNS, gateway email e servizi di reputazione possono comunque segnalare un dominio dannoso.
HIBS ha inoltre escluso dalla propria valutazione alcune variabili, tra cui allowlist remote, controlli di reputazione e determinati comportamenti di reindirizzamento. Un sito predisposto per l’attacco potrebbe quindi incontrare altre difese che il proof of concept non ha testato.
Vale anche il contrario. Un dominio di phishing appena creato potrebbe inizialmente disporre di pochi dati di reputazione. Gli attaccanti spesso sfruttano quell’intervallo prima che i sistemi automatizzati classifichino l’infrastruttura o che i difensori completino una rimozione.
Questo spiega perché il caso limite conta anche quando esistono più salvaguardie. La sicurezza a più livelli funziona meglio quando i fallimenti sono indipendenti. In questo caso, diversi controlli si basano su rappresentazioni scheletriche e liste di domini strettamente correlate, perciò un carattere scelto con cura può influenzare più di una decisione.
La protezione basata sulla cronologia implica inoltre che due utenti possano ricevere trattamenti diversi. Un visitatore abituale di un servizio protetto fornisce al browser un dominio noto da confrontare. Un visitatore alla prima esperienza potrebbe avere solo l’elenco di popolarità incluso.
Questa distinzione è particolarmente rilevante per siti di recruiting, banche regionali, software aziendale e portali dei fornitori. I dipendenti possono ricevere un link a un servizio che non hanno mai visitato, lasciando al browser una minore cronologia personale per il confronto.
La conclusione più prudente non è che Chromium non fornisca alcuna protezione. Le sue regole bloccano molte sostituzioni comuni prima che raggiungano gli utenti. La lezione è che l’aspetto della barra degli indirizzi e l’assenza di un avviso non possono, da soli, stabilire l’autenticità.
Gli attacchi omografici IDN vanno oltre la barra degli indirizzi
Il browser è solo una superficie di visualizzazione, mentre i domini ingannevoli possono raggiungere gli utenti tramite email, applicazioni di messaggistica, documenti e risultati di ricerca.
Un attacco omografico IDN utilizza caratteri diversi dall’aspetto simile per impersonare un altro identificatore. Il typosquatting è la pratica più ampia di registrare alternative confondibili a un dominio legittimo, incluse semplici grafie errate e caratteri visivamente ingannevoli.
La nuova ricerca si colloca nel punto in cui queste categorie si sovrappongono. I domini non sono errori convenzionali di digitazione, ma la loro somiglianza visiva può sfruttare la lettura rapida, gli schermi piccoli e le forme familiari dei marchi.
L’email crea un passaggio particolarmente difficile. Le regole sugli indirizzi di Chromium proteggono gli hostname resi dall’interfaccia del browser. Non regolano automaticamente il testo Unicode che un’applicazione di webmail inserisce nell’intestazione di un messaggio.
HIBS ha testato 20 domini di mittenti internazionalizzati in Gmail e Outlook sul web. I ricercatori riferiscono che Gmail ha visualizzato tutti e 20 in Unicode, inclusi domini che la barra degli indirizzi di Chromium avrebbe reso come Punycode.
Secondo il test, Gmail ha mantenuto la forma codificata in un campo mailed-by separato. È più probabile che la maggior parte dei destinatari esamini la riga del mittente in evidenza piuttosto che espandere le informazioni tecniche di consegna.
Nel test dei ricercatori, Outlook sul web ha adottato l’approccio opposto. Ha visualizzato tutti i 20 domini dei mittenti come etichette compatibili con ASCII, inclusi normali nomi internazionali come café.com e zürich.com.
Nessuno dei due approcci risolve completamente il compromesso sottostante. Decodificare tutto offre agli utenti indirizzi internazionali leggibili ma preserva l’ambiguità visiva. Codificare tutto espone le differenze, rendendo però gli indirizzi multilingue legittimi insoliti e difficili da interpretare.
Le applicazioni di messaggistica e i documenti possono introdurre lo stesso divario. Una piattaforma può rendere un link Unicode come testo ordinario prima che il browser riceva la destinazione selezionata. L’utente valuta una visualizzazione e poi naviga attraverso un altro sistema di sicurezza.
Risultati di ricerca e pubblicità aggiungono un’altra via. Un dominio ingannevole può apparire accanto a branding familiare e titoli di pagine copiati. Anche se l’indirizzo differisce leggermente, il contesto circostante può incoraggiare l’utente a completare il modello visivo.
I codici QR eliminano quasi completamente la destinazione visibile fino alla scansione. I browser mobili dispongono inoltre di meno spazio per gli hostname e le interfacce possono enfatizzare il titolo di una pagina rispetto all’indirizzo completo.
Il Consorzio Unicode raccomanda diverse difese per gli IDN confondibili. Tra queste figurano la limitazione dei repertori di caratteri consentiti, la prevenzione della rischiosa mescolanza di scritture, l’applicazione di vincoli linguistici contestuali e il blocco delle registrazioni che somigliano a etichette esistenti.
Le sue linee guida sulla sicurezza IDN sottolineano inoltre un’importante precisazione. I caratteri confondibili Unicode rappresentano solo una piccola parte del phishing. Domini semplici come secure-brand-login.com rimangono più comuni e non richiedono caratteri insoliti.
Questo contesto impedisce che le nuove scoperte diventino un’affermazione secondo cui Unicode abbia creato la maggior parte delle frodi online. Gli attaccanti scelgono in genere il metodo più economico che funziona. Una parola familiare, un sottodominio fuorviante, un account rubato o un sito legittimo compromesso possono essere più semplici da usare rispetto alla costruzione di un IDN sofisticato.
Tuttavia, una minore prevalenza non elimina il rischio per obiettivi di alto valore. Piattaforme di identità, servizi finanziari, console cloud e portali per dipendenti offrono agli attaccanti credenziali preziose. Un’imitazione visivamente convincente può valere lo sforzo aggiuntivo.
L’internazionalizzazione in sé non è il difetto. Internet deve supportare nomi scritti al di fuori dell’alfabeto latino di base. Trattare ogni indirizzo di questo tipo come ostile trasferirebbe l’onere sugli utenti e sulle aziende legittime.
La questione irrisolta è dove debba operare ciascuna difesa. I browser controllano la visualizzazione e gli avvisi di navigazione. I registri controllano quali etichette possono essere registrate. I servizi email controllano la presentazione del mittente. I titolari dei marchi monitorano le registrazioni sospette, mentre i team di sicurezza le filtrano e le indagano.
Nessun partecipante vede l’intero percorso dell’attacco. Questa frammentazione consente a un dominio rifiutato da un’interfaccia di apparire convincente in un’altra.
I registri non possono lasciare lo spoofing IDN di Chromium ai browser
La difesa più duratura inizia prima della navigazione, ma le politiche dei registri restano frammentate tra lingue e domini di primo livello.
Un dominio non può supportare un sito web o una casella di posta indipendenti a meno che un registro non ne consenta la registrazione. I controlli dei registri possono quindi bloccare nomi ingannevoli prima che i browser debbano decidere come visualizzarli.
Le politiche sui domini internazionalizzati utilizzano comunemente tabelle IDN. Queste tabelle definiscono quali caratteri Unicode un dominio di primo livello accetta e quali combinazioni o varianti richiedono un trattamento speciale.
Il Consorzio Unicode raccomanda di raggruppare o bloccare le etichette confondibili. Il raggruppamento assegna varianti correlate allo stesso registrante. Il blocco consente l’esistenza di un’etichetta impedendo al contempo la registrazione di alternative confondibili.
Le linee guida di implementazione IDN di ICANN stabiliscono aspettative generali volte a ridurre il cybersquatting e la confusione dei consumatori. Le politiche effettive variano comunque, poiché registri diversi supportano lingue, scritture e requisiti locali differenti.
Il registro .com ha consentito le registrazioni proof-of-concept di HIBS. Ciò non significa che .com accetti ogni sequenza Unicode. Significa che i caratteri e le combinazioni testati rientravano nelle regole di registrazione applicabili.
HIBS ha inoltre analizzato il file di zona .com ottenuto tramite il Centralized Zone Data Service di ICANN nell’ottobre 2026. I ricercatori hanno contato 167.226.216 nomi .com delegati, di cui 733.509 rappresentati in forma IDN.
La loro metodologia ha associato gli IDN ai domini ASCII delegati che assomigliavano loro visivamente. Ha prodotto 161.894 coppie di sosia che coprivano 133.953 nomi ASCII distinti.
Questi numeri non sono un conteggio di domini dannosi. I ricercatori avvertono esplicitamente che una coppia visiva può rappresentare una registrazione difensiva, un sito web multilingue o un’organizzazione non correlata.
La distinzione è essenziale. Un dominio contenente un carattere accentato può assomigliare a un nome ASCII per coincidenza. Proprietà, contenuti, comportamento DNS, certificati, configurazione email e reindirizzamenti forniscono prove più solide di intento dannoso.
Ciononostante, la scala mostra perché le liste dei browser non possono enumerare ogni obiettivo rilevante. Le protezioni incluse in Chromium coprono migliaia di nomi importanti, mentre la zona .com contiene milioni di aziende e organizzazioni che potrebbero subire impersonazioni.
Le piccole imprese possono essere particolarmente esposte. È meno probabile che i loro domini compaiano nelle liste di popolarità globali, eppure i loro clienti potrebbero fidarsi di fatture, portali dei fornitori e messaggi di reimpostazione della password che riportano il nome dell’azienda.
Un registro potrebbe rispondere vietando un carattere appena identificato in contesti specifici. Questo approccio può chiudere un caso limite, ma potrebbe anche escludere parole e comunità valide che dipendono da quel carattere.
Una politica più precisa può definire le varianti in base a relazioni specifiche della lingua. Tuttavia, la somiglianza visiva dipende da font, dimensione, lettere vicine e familiarità del lettore. Una sequenza ovvia per chi parla inglese può essere una parola legittima in un’altra lingua.
La registrazione difensiva offre un’altra opzione. Un marchio può registrare le varianti probabili e reindirizzarle al dominio autentico. Il codice di navigazione di Chromium riconosce alcuni reindirizzamenti sicuri, contribuendo a evitare avvisi per varianti controllate dall’organizzazione reale.
Questa strategia non è perfettamente scalabile. Unicode contiene molte potenziali sostituzioni e le politiche di registrazione cambiano tra domini di primo livello. Acquistare ogni possibile sosia imporrebbe un costo continuo e lascerebbe comunque lacune.
Il monitoraggio offre una copertura più ampia. I team di sicurezza possono osservare nuove registrazioni, emissioni di certificati, modifiche DNS e comportamenti di hosting per nomi simili a domini importanti. Il rilevamento precoce supporta richieste di rimozione e blocchi prima che un attacco raggiunga molte persone.
Le organizzazioni dovrebbero inoltre proteggere i flussi di lavoro ad alto rischio al di fuori del browser. I gestori di password associano le credenziali a origini esatte, rendendo meno probabile il riempimento automatico su un dominio sosia. Le passkey associano l’autenticazione al dominio del sito legittimo e resistono al phishing convenzionale delle credenziali.
I dipendenti che gestiscono pagamenti o recupero degli account necessitano di percorsi di verifica che non dipendano dall’aspetto di un link. Segnalibri noti, portali applicativi gestiti e canali di contatto confermati in modo indipendente riducono la dipendenza dal riconoscimento visivo dei domini.
Queste misure affrontano più dei sosia Unicode di Chromium. Aiutano anche contro errori ortografici comuni, sottodomini fuorvianti, caselle di posta compromesse e pagine di accesso clonate.
La pressione ricade quindi su più parti contemporaneamente. Chromium deve affinare le proprie euristiche. I registri necessitano di politiche sulle varianti più solide. I provider email necessitano di visualizzazioni dei mittenti più chiare. Le organizzazioni necessitano di controlli che presuppongano che gli utenti talvolta leggeranno male un indirizzo.
Ciò che accadrà dopo mostrerà se il divario si chiuderà davvero
Tre segnali determineranno se questa ricerca produrrà una difesa duratura o soltanto un’altra voce nella storia dei sosia corretti con patch.
Il primo segnale è una modifica alle regole di Chromium. La risposta più chiara affronterebbe il cirillico ө, il latino ƙ o la logica di diramazione che consente a un carattere non presente nell’elenco di aggirare una valutazione dell’intera scrittura.
La semplice aggiunta di due caratteri fermerebbe gli esempi pubblicati. Non risolverebbe necessariamente il problema strutturale. Un altro carattere con un segno visibile o una mappatura scheletrica insolita potrebbe ricreare lo stesso risultato.
Un fix più ampio potrebbe confrontare l’impressione resa tramite ulteriori trasformazioni scheletriche. Tuttavia, confronti più permissivi aumentano i falsi positivi, in particolare per i nomi internazionali legittimi.
Il codice pubblico e i test di Chromium rendono questo processo osservabile. I ricercatori di sicurezza possono verificare se una patch blocca le prove registrate preservando al contempo i domini ordinari nelle lingue interessate.
Il secondo segnale è l’azione dei registri. Tabelle IDN aggiornate potrebbero classificare questi caratteri come varianti in contesti specifici o impedire registrazioni che imitano etichette ASCII consolidate.
L’azione dei registri rafforzerebbe il giudizio principale dell’articolo perché blocca i nomi ingannevoli prima che emergano differenze di visualizzazione. Una patch limitata al browser lascerebbe i domini disponibili per i client email e altre applicazioni con regole di rendering diverse.
Il terzo segnale è un cambiamento nella presentazione della posta. HIBS ha rilevato che Gmail decodificava tutti i domini dei mittenti testati, mentre Outlook mostrava le etichette codificate. Futuri cambiamenti dell’interfaccia potrebbero esporre entrambe le forme, segnalare identità visive miste o avvertire quando un mittente assomiglia a un dominio noto.
Questo segnale conta perché l’email resta un canale naturale per il furto di credenziali e le frodi sui pagamenti. Una patch di Chromium non può proteggere da un nome di mittente ingannevole reso come testo all’interno di un’applicazione web.
I ricercatori dovranno inoltre ripetere i test dopo gli aggiornamenti. Il lavoro originale ha esaminato specifici comportamenti dei browser, nomi registrati e caselle di posta di prova in un determinato momento. Non ha stabilito che ogni build di Chromium, sistema operativo, font o applicazione email renderà i caratteri in modo identico.
Le differenze tra font possono indebolire o rafforzare l’illusione. A dimensioni maggiori, la barra su ө è più facile da notare. All’interno di una barra degli indirizzi compatta o di un campo mittente, tale distinzione potrebbe risultare meno evidente.
Le registrazioni segnalate dimostrano inoltre la possibilità, non uno sfruttamento diffuso. Prove pubbliche di campagne di phishing che utilizzano esattamente questi caratteri aumenterebbero l’urgenza. L’assenza di tali segnalazioni non dimostrerebbe che la lacuna è innocua, ma influirebbe sulla priorità del rischio.
Per gli utenti, la lezione immediata è più circoscritta di “non fidarti mai di Unicode”. Verifica le richieste inattese tramite un canale noto, soprattutto se riguardano credenziali, pagamenti o recupero dell’account. Un segnalibro o un gestore di password offre un riferimento migliore della sola ispezione visiva.
Per gli amministratori, occorre censire i domini più importanti e monitorare le registrazioni che li somigliano. Richiedere un’autenticazione resistente al phishing per i sistemi sensibili. Considerare i nuovi dettagli di fornitori o pagamenti come un evento da verificare, non come una normale attività via email.
Per i team di prodotto, testare il modo in cui le applicazioni visualizzano indirizzi del mittente e link internazionalizzati. Mostrare un nome Unicode leggibile senza alcun accesso alla forma codificata può nascondere elementi di prova utili. Mostrare solo Punycode può rendere inutilmente ostili le identità internazionali legittime.
Le difese di Chromium contro lo spoofing IDN restano solide, ma questa ricerca dimostra che solido non significa completo. Il browser blocca le sostituzioni evidenti tra scritture diverse e i noti trucchi basati su interi alfabeti, quindi verifica le destinazioni popolari e familiari durante la navigazione.
Un carattere scelto con cura può ancora alterare il confronto effettuato dalla macchina senza cambiare l’impressione percepita da una persona di fretta. Questo divario è piccolo nel codice, ma significativo ovunque la fiducia dipenda dal riconoscere un nome.
I prossimi mesi dovrebbero rivelare se Chromium, i registri e i fornitori di posta tratteranno gli esempi come aggiunte isolate a un elenco o come prova che i livelli richiedono presupposti diversi. Nel frattempo, le organizzazioni dovrebbero testare i propri domini, rafforzare l’autenticazione vincolata all’origine e smettere di chiedere agli utenti di prendere decisioni di sicurezza basandosi soltanto sulla tipografia.
