Les défenses de Chromium contre l’usurpation IDN manquent des domaines ressemblants convaincants
Les défenses de Chromium contre l’usurpation IDN n’ont pas détecté 20 domaines ressemblants enregistrés, malgré des années de protections conçues pour révéler les adresses Unicode trompeuses. Un domaine de démonstration ressemblait fortement à apple.com tout en s’affichant en Unicode lisible, plutôt que dans le format Punycode bien visible commençant par xn--.
Cette découverte ne signifie pas que des attaquants ont enregistré le domaine d’Apple ou compromis son infrastructure. Les chercheurs de Have I Been Squatted, ou HIBS, ont enregistré un autre domaine dont les caractères cyrilliques ressemblent aux lettres latines d’« apple ». Leurs tests montrent comment des caractères soigneusement choisis peuvent contourner les règles d’affichage de Chromium et ses défenses distinctes appliquées lors de la navigation.
Ce résultat ravive un dilemme que les navigateurs gèrent depuis l’adoption généralisée des noms de domaine internationalisés. Le web a besoin d’adresses écrites dans les langues réellement utilisées par les internautes. Toutefois, cette même diversité de caractères offre aux attaquants davantage de moyens d’imiter des marques de confiance, des fournisseurs d’identité et des services de paiement.
Chromium applique déjà l’un des systèmes de défense les plus détaillés du secteur. Il vérifie les systèmes d’écriture, les combinaisons de caractères suspectes, les domaines connus et l’historique de navigation. Les nouveaux exemples n’annulent pas ces protections. Ils révèlent comment quelques caractères peuvent passer entre des couches qui prennent chacune des décisions légèrement différentes.
Les chercheurs ont identifié un nouveau cas limite d’usurpation IDN dans Chromium
L’élément important n’est pas le retour d’une attaque oubliée, mais la preuve que les vérifications actuelles de Chromium autorisent encore de nouvelles variantes convaincantes.
Les chercheurs de HIBS, Ian Muscat et Leanne Briffa, ont publié leur analyse le 3 octobre 2026. Ils ont cherché à déterminer si un domaine internationalisé pouvait ressembler à une adresse célèbre en alphabet latin tout en restant affiché en Unicode dans les navigateurs basés sur Chromium.
Un nom de domaine internationalisé, ou IDN, contient des caractères dépassant l’alphabet anglais de base. Les applications traduisent ces caractères en une représentation compatible ASCII appelée Punycode avant d’effectuer une requête DNS. Un domaine commençant par xn-- n’est donc pas automatiquement dangereux. Il s’agit d’une forme encodée nécessaire au fonctionnement du système de noms de domaine existant.
Les navigateurs reconvertissent souvent cette forme encodée en Unicode lisible pour l’affichage. Cela prend en charge les adresses légitimes en arabe, cyrillique, chinois et dans de nombreux autres systèmes d’écriture. Le problème de sécurité apparaît lorsque des caractères différents ont des formes presque identiques.
Les chercheurs se sont concentrés sur аррӏө.com, un domaine qui peut ressembler à apple.com dans les polices courantes. Ses lettres sont cyrilliques, y compris des caractères ayant la forme d’un « a » latin, de deux « p » et d’un « l ». Le dernier caractère cyrillique, ө, ressemble à un « e » arrondi lorsqu’il est affiché à la taille de la barre d’adresse.
L’adresse n’est pas apple.com. Sa forme encodée est xn--80a6aa68c8d.com, et le DNS la traite comme un nom distinct. Pourtant, la version lisible peut donner l’impression visuelle qu’un visiteur a atteint le domaine d’Apple.
HIBS a enregistré ce domaine et 19 autres noms ressemblants à titre de démonstration. La liste imitait des noms associés à OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike et d’autres organisations reconnues.
La recherche IDN originale indique que Chrome 154 affichait le domaine ressemblant à Apple en Unicode avec un certificat valide. Il a également passé les vérifications de navigation évaluées par les chercheurs sans déclencher d’avertissement de ressemblance.
Un certificat valide ne prouve pas qu’un domaine appartient à la marque à laquelle il ressemble. Il confirme que le navigateur a établi une connexion chiffrée avec le domaine nommé dans ce certificat. Des attaquants peuvent obtenir des certificats pour des domaines qu’ils contrôlent légitimement, y compris des domaines trompeurs.
Les exemples étaient des enregistrements contrôlés, et non la preuve d’une campagne visant les clients de toutes les entreprises citées. Cette distinction importe, car une usurpation techniquement réalisable n’est pas automatiquement une opération d’hameçonnage active.
Pourtant, c’est bien cette faisabilité technique qui constitue la découverte. Un domaine trompeur peut prendre en charge un véritable site web, HTTPS, des e-mails, des redirections et d’autres services Internet ordinaires. Des attaquants pourraient ensuite associer cette ressemblance visuelle à une publicité dans les résultats de recherche, un e-mail frauduleux, un code QR, un lien raccourci ou une page de connexion copiée.
La recherche a fait l’objet d’une couverture plus large le 18 octobre, lorsqu’une enquête sur le typosquattage a détaillé comment les substitutions cyrilliques avaient échappé aux règles de Chromium. Cette chronologie attire de nouveau l’attention sur des défenses que de nombreux utilisateurs ne voient jamais, sauf lorsque le navigateur détecte un élément suspect.
Cela crée la tension centrale de l’article. Chromium doit distinguer les substitutions visuelles trompeuses des mots légitimes utilisés par des millions de personnes. Une règle assez large pour détecter chaque ressemblance rendrait également les adresses internationales ordinaires plus difficiles à lire et à considérer comme fiables.
Comment les caractères Unicode ressemblants contournent plusieurs vérifications de Chromium
Le domaine ressemblant à Apple passe les contrôles parce qu’aucune règle unique de Chromium n’évalue l’impression visuelle complète perçue par l’utilisateur.
Chromium ne se contente pas de demander si un domaine contient de l’Unicode. Il traite les IDN au moyen de plusieurs tests avant de décider d’afficher des caractères lisibles ou l’étiquette Punycode sous-jacente.
La première couche majeure utilise le vérificateur d’usurpation d’International Components for Unicode. Chromium le configure au niveau « Highly Restrictive », qui limite les combinaisons suspectes de systèmes d’écriture.
Une étiquette mixte contenant un caractère cyrillique parmi des lettres latines échoue normalement à ce test. Remplacer uniquement le premier « a » de apple.com, par exemple, conduit Chromium à afficher xn--pple-43d.com. L’adresse encodée risque beaucoup moins d’être confondue avec l’originale.
Le nouveau domaine ressemblant à Apple évite ce résultat, car chaque lettre avant .com est cyrillique. Il s’agit d’une étiquette à un seul système d’écriture, et non d’un mélange évident de caractères latins et cyrilliques.
Chromium maintient également un ensemble de caractères autorisés. Il exclut divers blocs Unicode et points de code individuels associés à des affichages risqués ou confus. Les caractères de аррӏө.com restent admissibles, notamment parce qu’il s’agit de lettres légitimes utilisées dans de vraies langues.
Plusieurs vérifications ciblées suivent. Chromium restreint le thorn et l’eth islandais en dehors des domaines nationaux concernés. Il limite le schwa ադրբեջanais et applique une règle spécifique au point médian catalan. Aucune de ces restrictions ne concerne la séquence cyrillique utilisée dans la démonstration.
La défense la plus pertinente est la vérification de caractères confusibles à l’échelle d’un système d’écriture de Chromium. Elle recherche les étiquettes entièrement écrites en caractères cyrilliques qui ressemblent tous à des lettres latines.
Chromium a introduit cette protection après une démonstration largement commentée en 2017. Le chercheur en sécurité Xudong Zheng avait enregistré une version entièrement cyrillique de apple.com que les navigateurs affichaient comme une copie visuelle proche de l’adresse réelle.
Chromium a réagi dans Chrome 58. Sa vérification à l’échelle d’un système d’écriture identifie un ensemble de 29 caractères cyrilliques ressemblant à des caractères latins. Lorsque chaque lettre d’une étiquette à un seul système appartient à cet ensemble, Chromium peut afficher le domaine en Punycode.
Cette défense détecte la version de 2017. Elle ne détecte pas la nouvelle variante, car ө ne figure pas parmi les 29 caractères répertoriés. Un seul caractère hors de cet ensemble suffit à désactiver la condition applicable à l’ensemble du système d’écriture, même si l’étiquette complète ressemble toujours à « apple ».
Le navigateur doit autoriser ce caractère quelque part, car ce n’est pas un symbole inventé. Le ө cyrillique est utilisé en kazakh, en mongol, en tatar et dans d’autres langues. Le bloquer partout imposerait un coût d’utilisabilité aux locuteurs légitimes.
Chromium utilise ensuite une comparaison par squelette pour les domaines protégés. Un squelette réduit les caractères visuellement apparentés à une représentation normalisée que le logiciel peut comparer à des noms connus.
Le procédé est utile, mais il ne peut pas reproduire parfaitement la vision humaine. Dans ce cas, la barre transversale du ө survit à la normalisation. Le squelette obtenu se termine par une forme fondée sur un « o » associé à une marque combinatoire, plutôt que par le « e » latin attendu.
Cette différence empêche une correspondance exacte avec le squelette de apple.com. Une petite marque suffit à modifier le résultat informatique, même lorsqu’elle devient difficile à percevoir dans une interface de navigateur compacte.
Les exemples en alphabet latin révèlent une faiblesse connexe. Les chercheurs ont utilisé des caractères tels que ƙ, une lettre latine munie d’un crochet, pour imiter le « k » dans des noms comprenant Okta et Nike. Chromium ne peut pas appliquer un avertissement général à l’échelle d’un système d’écriture aux caractères latins, car les domaines latins accentués sont courants et légitimes.
Chromium accorde plutôt une protection par squelette plus forte à une liste intégrée de domaines importants. HIBS a trouvé 8 462 noms dans cette liste, dont 836 dans un groupe de priorité plus élevée. Toutefois, un caractère qui conserve une marque supplémentaire peut empêcher une correspondance exacte du squelette.
Les directives d’affichage de Chromium reconnaissent cet équilibre fondamental. Chrome affiche le Punycode lorsque ses règles d’affichage des IDN identifient un risque d’homographie, mais évite de traiter chaque adresse non ASCII comme hostile.
Cet équilibre fait de l’usurpation IDN dans Chromium un problème de classification plutôt qu’un simple problème de liste noire. Chaque nouvelle règle doit détecter les ressemblances malveillantes sans transformer des noms internationaux légitimes en chaînes encodées illisibles.
Les avertissements du navigateur fournissent une seconde défense, avec des limites
Un domaine affiché en Unicode reste soumis à des vérifications lors de la navigation, mais celles-ci dépendent de comparaisons exactes, de la longueur du nom et de l’historique du visiteur.
Chromium sépare l’affichage de l’adresse de la protection appliquée lors de la navigation. Le premier système détermine l’apparence d’un nom d’hôte dans la barre d’adresse. Le second peut interrompre ou signaler une visite après la navigation de l’utilisateur.
Le composant de navigation contre les noms ressemblants de Chromium compare une adresse visitée à des domaines populaires et à des sites que l’utilisateur visite régulièrement. Selon la correspondance, Chrome peut afficher une page d’avertissement complète ou un Safety Tip moins intrusif.
La conception des avertissements contre les noms ressemblants décrit ces vérifications comme une couche supplémentaire aux côtés de Google Safe Browsing. La popularité et l’engagement antérieur d’un utilisateur fournissent au navigateur des points de référence pour identifier des alternatives suspectes.
HIBS indique qu’une correspondance exacte de squelette avec l’un des 836 domaines les plus prioritaires produit une page d’avertissement. Une correspondance exacte avec un autre domaine intégré peut produire un Safety Tip.
Le navigateur tient également compte des sites qu’un utilisateur visite avec une fréquence suffisante. Si une nouvelle adresse ressemble exactement à l’un de ces sites fréquemment visités, Chromium peut bloquer la navigation et demander si le visiteur souhaitait ouvrir le domaine familier.
Les correspondances proches font l’objet d’un traitement plus restreint. Chromium peut détecter un squelette qui diffère d’un caractère inséré, supprimé ou remplacé. Il peut aussi reconnaître une permutation de deux caractères voisins.
Ces comparaisons ne s’appliquent pas uniformément. Selon la recherche, le test de correspondance proche ignore les étiquettes cibles de moins de cinq caractères avant le domaine de premier niveau. Cela compte pour les marques aux noms courts.
Le domaine ressemblant à Okta utilisant ƙ ne diffère que d’une modification du nom réel, mais « okta » compte quatre caractères. Les chercheurs indiquent que cela le rend trop court pour la vérification de correspondance proche concernée.
L’exemple Apple échoue pour une autre raison. Son squelette ne diffère de apple.com que de deux modifications, car ө se normalise en un « o » plus une barre conservée. La comparaison de quasi-correspondance n’autorise qu’une seule modification.
Par conséquent, le domaine testé s’affichait en Unicode et se chargeait sans avertissement concernant une ressemblance trompeuse. HIBS indique que cela restait vrai même pour une personne qui visitait régulièrement le site web authentique d’Apple.
Ces résultats ne doivent pas être interprétés comme un audit complet de toutes les protections entourant une visite. Safe Browsing, les flux de renseignement sur les menaces, les logiciels de protection des terminaux, le filtrage DNS, les passerelles de messagerie et les services de réputation peuvent encore signaler un domaine malveillant.
HIBS a également exclu certaines variables de son évaluation, notamment les listes d’autorisation distantes, les contrôles de réputation et certains comportements de redirection. Un site armé pourrait donc rencontrer d’autres défenses que la preuve de concept n’a pas testées.
L’inverse est également vrai. Un domaine de phishing nouvellement créé peut initialement disposer de peu de données de réputation. Les attaquants exploitent souvent cet intervalle avant que les systèmes automatisés classent l’infrastructure ou que les défenseurs finalisent son retrait.
Cela explique pourquoi ce cas limite importe même lorsque plusieurs protections existent. La sécurité en couches fonctionne mieux lorsque les défaillances sont indépendantes. Ici, plusieurs vérifications reposent sur des représentations de squelettes et des listes de domaines étroitement liées ; un caractère choisi avec soin peut donc influencer plusieurs décisions.
La protection fondée sur l’historique signifie aussi que deux utilisateurs peuvent recevoir un traitement différent. Un visiteur régulier d’un service protégé fournit au navigateur un domaine connu à comparer. Un visiteur qui s’y rend pour la première fois ne dispose peut-être que de la liste de popularité intégrée.
Cette distinction est particulièrement pertinente pour les sites de recrutement, les banques régionales, les logiciels d’entreprise et les portails fournisseurs. Des employés peuvent recevoir un lien vers un service qu’ils n’ont jamais visité, laissant au navigateur moins d’historique personnel pour la comparaison.
La conclusion la plus prudente n’est pas que Chromium n’offre aucune protection. Ses règles bloquent de nombreuses substitutions courantes avant qu’elles n’atteignent les utilisateurs. La leçon est que l’apparence de la barre d’adresse et l’absence d’avertissement ne peuvent, à elles seules, établir l’authenticité.
Les attaques homographiques IDN dépassent la barre d’adresse
Le navigateur n’est qu’une surface d’affichage parmi d’autres, tandis que des domaines trompeurs peuvent atteindre les utilisateurs par e-mail, applications de messagerie, documents et résultats de recherche.
Une attaque homographique IDN utilise des caractères différents qui se ressemblent afin d’usurper un autre identifiant. Le typosquatting désigne plus largement la pratique consistant à enregistrer des variantes confusantes d’un domaine légitime, y compris de simples fautes de frappe et des caractères visuellement trompeurs.
La nouvelle recherche se situe à l’intersection de ces catégories. Les domaines ne sont pas de simples erreurs de saisie au clavier, mais leur similitude visuelle peut exploiter une lecture rapide, les petits écrans et les formes familières des marques.
L’e-mail crée un passage particulièrement difficile à sécuriser. Les règles d’adresse de Chromium protègent les noms d’hôtes affichés par l’interface du navigateur. Elles ne régissent pas automatiquement le texte Unicode qu’une application de webmail place dans l’en-tête d’un message.
HIBS a testé 20 domaines expéditeurs internationalisés dans Gmail et Outlook sur le web. Les chercheurs rapportent que Gmail les a tous affichés en Unicode, y compris des domaines que la barre d’adresse de Chromium aurait rendus en Punycode.
Gmail a conservé la forme encodée dans un champ mailed-by distinct, selon le test. La plupart des destinataires sont plus susceptibles d’examiner la ligne d’expéditeur mise en avant que de développer les informations techniques de livraison.
Outlook sur le web a adopté l’approche inverse lors du test des chercheurs. Il a affiché les 20 domaines expéditeurs sous forme de libellés compatibles ASCII, y compris des noms internationaux ordinaires tels que café.com et zürich.com.
Aucune des deux approches ne résout entièrement le compromis sous-jacent. Tout décoder offre aux utilisateurs des adresses internationales lisibles, mais conserve l’ambiguïté visuelle. Tout encoder révèle les différences, tout en rendant les adresses multilingues légitimes inhabituelles et difficiles à interpréter.
Les applications de messagerie et les documents peuvent créer le même écart. Une plateforme peut afficher un lien Unicode sous forme de texte ordinaire avant que le navigateur ne reçoive la destination sélectionnée. L’utilisateur évalue un affichage, puis navigue via un autre système de sécurité.
Les résultats de recherche et les publicités ajoutent une autre voie. Un domaine trompeur peut apparaître à côté d’une identité visuelle familière et de titres de pages copiés. Même si l’adresse diffère légèrement, le contexte environnant peut encourager l’utilisateur à compléter mentalement le schéma visuel.
Les codes QR éliminent presque entièrement la destination visible jusqu’au scan. Les navigateurs mobiles disposent aussi de moins d’espace pour les noms d’hôtes, et les interfaces peuvent mettre en avant le titre d’une page plutôt que l’adresse complète.
Le Consortium Unicode recommande plusieurs défenses contre les IDN confusables. Elles comprennent la limitation des répertoires de caractères autorisés, la prévention des mélanges risqués d’écritures, l’application de contraintes linguistiques contextuelles et le blocage des enregistrements qui ressemblent à des libellés existants.
Ses recommandations de sécurité IDN soulignent également une nuance importante. Les confusables Unicode ne représentent qu’une petite part du phishing. Des domaines simples tels que secure-brand-login.com restent plus fréquents et ne nécessitent aucun caractère inhabituel.
Ce contexte empêche de transformer les nouvelles conclusions en affirmation selon laquelle Unicode serait à l’origine de la plupart des fraudes en ligne. Les attaquants choisissent généralement la méthode la moins coûteuse qui fonctionne. Un mot familier, un sous-domaine trompeur, un compte volé ou un site légitime compromis peut être plus facile à utiliser que la création d’un IDN sophistiqué.
Toutefois, une prévalence moindre n’élimine pas le risque pour les cibles à forte valeur. Les plateformes d’identité, les services financiers, les consoles cloud et les portails employés offrent aux attaquants des identifiants précieux. Une usurpation visuellement convaincante peut justifier l’effort supplémentaire.
L’internationalisation n’est pas elle-même la faille. Internet doit prendre en charge les noms écrits au-delà de l’alphabet latin de base. Traiter chaque adresse de ce type comme hostile reporterait la charge sur les utilisateurs et entreprises légitimes.
La question non résolue est de savoir où chaque défense doit intervenir. Les navigateurs contrôlent l’affichage et les avertissements de navigation. Les registres contrôlent les libellés pouvant être enregistrés. Les services de messagerie contrôlent la présentation de l’expéditeur. Les propriétaires de marques surveillent les enregistrements suspects, tandis que les équipes de sécurité les filtrent et les analysent.
Aucun intervenant ne voit l’intégralité du parcours d’attaque. Cette fragmentation permet à un domaine rejeté par une interface de paraître convaincant dans une autre.
Les registres ne peuvent pas laisser l’usurpation IDN de Chromium aux seuls navigateurs
La défense la plus durable commence avant la navigation, mais les politiques des registres restent fragmentées selon les langues et les domaines de premier niveau.
Un domaine ne peut prendre en charge un site web ou une boîte aux lettres indépendante que si un registre autorise son enregistrement. Les contrôles des registres peuvent donc bloquer des noms trompeurs avant que les navigateurs aient à décider comment les afficher.
Les politiques relatives aux noms de domaine internationalisés utilisent couramment des tables IDN. Ces tables définissent quels caractères Unicode un domaine de premier niveau accepte et quelles combinaisons ou variantes nécessitent un traitement particulier.
Le Consortium Unicode recommande de regrouper ou de bloquer les libellés confusables. Le regroupement attribue des variantes apparentées au même titulaire. Le blocage permet à un libellé d’exister tout en empêchant l’enregistrement d’alternatives confusantes.
Les lignes directrices de mise en œuvre des IDN de l’ICANN établissent des attentes générales visant à réduire le cybersquatting et la confusion des consommateurs. Les politiques réelles varient toutefois encore, car les différents registres prennent en charge différentes langues, écritures et exigences locales.
Le registre .com a autorisé les enregistrements de preuve de concept de HIBS. Cela ne signifie pas que .com accepte toutes les séquences Unicode. Cela signifie que les caractères et combinaisons testés respectaient les règles d’enregistrement applicables.
HIBS a également analysé le fichier de zone .com obtenu via le Centralized Zone Data Service de l’ICANN en octobre 2026. Les chercheurs ont compté 167,226,216 noms .com délégués, dont 733,509 représentés sous forme IDN.
Leur méthodologie a associé les IDN aux domaines ASCII délégués auxquels ils ressemblaient visuellement. Elle a produit 161,894 paires ressemblantes couvrant 133,953 noms ASCII distincts.
Ces chiffres ne constituent pas un décompte des domaines malveillants. Les chercheurs avertissent explicitement qu’une paire visuelle peut correspondre à un enregistrement défensif, à un site web multilingue ou à une organisation sans lien.
Cette distinction est essentielle. Un domaine contenant un caractère accentué peut ressembler par coïncidence à un nom ASCII. La propriété, le contenu, le comportement DNS, les certificats, la configuration e-mail et les redirections offrent des preuves plus solides d’une intention malveillante.
Malgré tout, l’ampleur montre pourquoi les listes des navigateurs ne peuvent pas énumérer toutes les cibles pertinentes. Les protections intégrées de Chromium couvrent des milliers de noms importants, tandis que la zone .com contient des millions d’entreprises et d’organisations susceptibles d’être usurpées.
Les petites entreprises peuvent être particulièrement exposées. Leurs domaines sont moins susceptibles de figurer dans les listes de popularité mondiales, alors que leurs clients peuvent faire confiance à des factures, portails fournisseurs et messages de réinitialisation de mot de passe portant le nom de l’entreprise.
Un registre pourrait réagir en interdisant un caractère nouvellement identifié dans certains contextes. Cette approche peut fermer un cas limite, mais elle risque aussi d’exclure des mots valides et des communautés qui dépendent de ce caractère.
Une politique plus précise peut définir des variantes selon des relations propres à chaque langue. Cependant, la ressemblance visuelle dépend des polices, de la taille, des lettres voisines et de la familiarité du lecteur. Une séquence évidente pour un anglophone peut être un mot légitime dans une autre langue.
L’enregistrement défensif offre une autre option. Une marque peut enregistrer les variantes probables et les rediriger vers le domaine authentique. Le code de navigation de Chromium reconnaît certaines redirections sûres, ce qui aide à éviter les avertissements pour les variantes contrôlées par la véritable organisation.
Cette stratégie ne passe pas parfaitement à l’échelle. Unicode contient de nombreuses substitutions potentielles, et les politiques d’enregistrement changent selon les domaines de premier niveau. Acheter chaque ressemblance concevable imposerait un coût continu et laisserait malgré tout des lacunes.
La surveillance offre une couverture plus large. Les équipes de sécurité peuvent suivre les nouveaux enregistrements, l’émission de certificats, les changements DNS et le comportement d’hébergement des noms ressemblant à des domaines importants. Une détection précoce facilite les demandes de retrait et les blocages avant qu’une attaque n’atteigne de nombreux utilisateurs.
Les organisations devraient également protéger les flux de travail à haut risque en dehors du navigateur. Les gestionnaires de mots de passe associent les identifiants à des origines exactes, ce qui réduit la probabilité d’un remplissage automatique sur un domaine ressemblant. Les passkeys lient l’authentification au domaine du site légitime et résistent au phishing d’identifiants conventionnel.
Les employés qui gèrent des paiements ou la récupération de comptes ont besoin de voies de vérification qui ne reposent pas sur l’apparence d’un lien. Des favoris connus, des portails d’applications gérés et des canaux de contact confirmés indépendamment réduisent la dépendance à la reconnaissance visuelle des domaines.
Ces mesures vont au-delà des ressemblances Unicode dans Chromium. Elles aident également contre les fautes de frappe ordinaires, les sous-domaines trompeurs, les boîtes aux lettres compromises et les pages de connexion clonées.
La pression s’exerce donc simultanément sur plusieurs parties. Chromium doit affiner ses heuristiques. Les registres ont besoin de politiques de variantes plus robustes. Les fournisseurs de messagerie doivent proposer des affichages d’expéditeur plus clairs. Les organisations ont besoin de contrôles qui partent du principe que les utilisateurs liront parfois mal une adresse.
La suite montrera si la faille se referme réellement
Trois signaux détermineront si cette recherche produit une défense durable ou seulement une entrée supplémentaire dans l’histoire des ressemblances corrigées.
Le premier signal sera une modification des règles de Chromium. La réponse la plus claire traiterait le cyrillique ө, le latin ƙ, ou la logique de branchement qui permet à un caractère non répertorié de contourner une évaluation de l’ensemble de l’écriture.
Le simple ajout de deux caractères stopperait les exemples publiés. Cela ne résoudrait pas nécessairement le problème structurel. Un autre caractère doté d’une marque visible ou d’un mappage de squelette inhabituel pourrait reproduire le même résultat.
Une correction plus large pourrait comparer l’impression visuelle produite au moyen de transformations supplémentaires des squelettes. Toutefois, des comparaisons plus souples augmentent les faux positifs, en particulier pour les noms internationaux légitimes.
Le code public et les tests de Chromium rendent ce processus observable. Les chercheurs en sécurité peuvent vérifier si un correctif bloque les preuves enregistrées tout en préservant les domaines ordinaires dans les langues concernées.
Le deuxième signal est une action des registres. Des tables IDN mises à jour pourraient classer ces caractères comme des variantes dans certains contextes ou empêcher les enregistrements qui imitent des libellés ASCII établis.
Une action des registres renforcerait le jugement principal de l’article, car elle bloque les noms trompeurs avant que des différences d’affichage n’apparaissent. Un correctif limité au navigateur laisserait ces domaines disponibles pour les clients de messagerie et d’autres applications appliquant des règles de rendu différentes.
Le troisième signal est une évolution de la présentation des e-mails. HIBS a constaté que Gmail décodait tous les domaines d’expéditeur testés, tandis qu’Outlook affichait les libellés encodés. De futurs changements d’interface pourraient présenter les deux formes, signaler les identités visuelles mixtes ou avertir lorsqu’un expéditeur ressemble à un domaine connu.
Ce signal est important, car l’e-mail reste un vecteur naturel pour le vol d’identifiants et la fraude aux paiements. Un correctif Chromium ne peut pas protéger contre un nom d’expéditeur trompeur rendu sous forme de texte dans une application web.
Les chercheurs devront également retester ces conclusions après les mises à jour. Le travail initial examinait un comportement de navigateur spécifique, des noms enregistrés et des boîtes aux lettres de test à un moment donné. Il n’établissait pas que chaque version de Chromium, système d’exploitation, police ou application de messagerie rendra les caractères de manière identique.
Les différences de police peuvent affaiblir ou renforcer l’illusion. À plus grande taille, la barre traversant ө est plus facile à remarquer. Dans une barre d’adresse compacte ou un champ d’expéditeur, cette distinction peut être moins visible.
Les enregistrements signalés prouvent également une possibilité, et non une exploitation généralisée. Des preuves publiques de campagnes de phishing utilisant précisément ces caractères accroîtraient l’urgence. L’absence de tels signalements ne démontrerait pas que cette faille est inoffensive, mais elle influerait sur la priorisation des risques.
Pour les utilisateurs, la leçon immédiate est plus limitée que « ne faites jamais confiance à Unicode ». Vérifiez les demandes inattendues par un canal connu, surtout lorsqu’elles concernent des identifiants, des paiements ou la récupération de compte. Un marque-page ou un gestionnaire de mots de passe offre une meilleure référence qu’une simple inspection visuelle.
Pour les administrateurs, recensez les domaines les plus importants et surveillez les enregistrements qui leur ressemblent. Exigez une authentification résistante au phishing pour les systèmes sensibles. Considérez les nouvelles informations de fournisseur ou de paiement comme un événement à vérifier, et non comme une tâche routinière reçue par e-mail.
Pour les équipes produit, testez la manière dont les applications affichent les adresses d’expéditeur et les liens internationalisés. Afficher un nom Unicode convivial sans accès à la forme encodée peut masquer des éléments utiles. N’afficher que le Punycode peut rendre les identités internationales légitimes inutilement hostiles.
Les défenses de Chromium contre l’usurpation IDN restent solides, mais cette recherche démontre que solide ne signifie pas complet. Le navigateur bloque les substitutions évidentes entre scripts et les astuces connues reposant sur des scripts entiers, puis vérifie les destinations populaires et familières pendant la navigation.
Un caractère choisi avec soin peut encore modifier la comparaison effectuée par la machine sans changer l’impression perçue par une personne pressée. Cet écart est faible dans le code, mais significatif partout où la confiance dépend de la reconnaissance d’un nom.
Les prochains mois devraient révéler si Chromium, les registres et les fournisseurs de messagerie considèrent ces exemples comme des ajouts isolés à une liste ou comme la preuve que les différentes couches nécessitent des hypothèses différentes. D’ici là, les organisations devraient tester leurs propres domaines, renforcer l’authentification liée à l’origine et cesser de demander aux utilisateurs de prendre des décisions de sécurité sur la seule base de la typographie.
