Une attaque par homographes enregistre un domaine bâti à partir de caractères qui semblent identiques à ceux d'un domaine réel mais qui ne le sont pas - un "a" cyrillique se substituant à un "a" latin, par exemple - si bien que l'adresse qu'une personne lit et l'adresse que le navigateur résout sont deux choses différentes. Le procédé fonctionne parce que le système de noms de domaine ne comprend que l'ASCII, donc chaque domaine non-ASCII est traduit en une forme ASCII appelée punycode, signalée par un préfixe xn--, avant même de toucher le DNS. Les navigateurs le décodent ensuite pour l'affichage sous sa forme lisible, et c'est précisément dans cette étape de décodage que réside la tromperie.
Les navigateurs modernes interceptent désormais les cas évidents et affichent le punycode brut lorsqu'un libellé mélange des écritures de façon suspecte, ce qui ferme la porte à la plupart des attaques faciles qui fonctionnaient il y a dix ans. Mais cette protection ne sort pas de la barre d'adresse du navigateur.
Je passe ma vie professionnelle à examiner des cas d'usurpation de marque, et les bons faux m'accrochent encore l'oeil pendant une demi-seconde avant que le détail qui trahit ne s'impose. Cet article explique comment fonctionne une attaque par homographes, où s'arrête la défense du navigateur, et que faire face à cela - que vous soyez sur le point de cliquer, ou que vous soyez propriétaire du domaine usurpé. Pour la question plus large de savoir si les liens courts eux-mêmes sont dignes de confiance, les raccourcisseurs d'URL sont-ils sûrs traite ce sujet ; celui-ci porte sur le domaine qui se trouve sous le lien.
Ce qu'est le punycode et pourquoi il existe
Le DNS a été conçu pour l'ASCII, un point c'est tout. Il n'a aucun moyen natif de stocker les lettres accentuées, le cyrillique, l'arabe ou les caractères chinois qui composent la plupart des systèmes d'écriture du monde, ce qui est devenu un vrai problème dès que l'enregistrement de domaines s'est ouvert en dehors des marchés anglophones.
Le punycode est la solution : un encodage réversible, normalisé sous la RFC 3492, qui convertit un libellé Unicode en lettres, chiffres et traits d'union ASCII que le DNS peut transporter sans aucun changement au protocole de transport. Une boulangerie allemande qui enregistre un domaine avec un tréma, ou un commerçant ukrainien qui en enregistre un en cyrillique, obtient un nom de domaine internationalisé fonctionnel qui se résout exactement comme n'importe quel autre, parce qu'en dessous, ce n'est jamais qu'un autre libellé ASCII. La forme encodée commence toujours par xn--, signalant "ceci est du punycode, décodez avant de le montrer à un humain".
Rien de tout cela n'est une faille en soi - les noms de domaine internationalisés sont une fonctionnalité authentique et nécessaire, pas un contournement que quiconque devrait désactiver. Le problème commence un cran au-dessus, au moment où un navigateur décide comment vous réafficher ce nom décodé.
Comment fonctionne une attaque par homographes
Une attaque par homographes exploite l'écart entre ce que contient un domaine et son apparence une fois affiché. Deux variantes se rencontrent dans la nature, et elles ne sont pas également répandues.
La version à écriture entière enregistre un domaine entier dans une écriture non latine dont les formes de lettres ressemblent par hasard à la marque ciblée. Elle est voyante à bâtir et plus facile à repérer pour les défenseurs, puisque tout le libellé est étranger.
La version à écriture mixte est celle qui est réellement utilisée, parce qu'elle ne nécessite qu'une seule substitution. Prenez un domaine comme novacloud.com. Remplacez le "o" latin par le "о" cyrillique visuellement identique (U+043E) et vous obtenez nоvacloud.com - même forme, même longueur, point de code différent, et un domaine qui s'encode en xn--nvacloud-nbh.com. Tout le reste du libellé reste inchangé, si bien que l'oeil n'a presque rien à signaler. Les chercheurs en sécurité appellent ce type de paire de sosies un "confusable", et une poignée d'entre eux couvre la majeure partie de l'alphabet latin.
Une fois le domaine enregistré, le reste de l'attaque est du phishing ordinaire : une page de connexion copiée pixel par pixel, un message urgent pointant vers le lien usurpé, et une cible qui n'a aucune raison de douter d'une adresse qui semble parfaitement correcte.
Ce que font les navigateurs aujourd'hui pour s'en protéger
Les éditeurs de navigateurs ont fermé la version facile de cette attaque il y a des années grâce à une règle sur les écritures autorisées à se mélanger dans un même libellé. La politique de Chrome, documentée dans son guide de gestion des IDN, vérifie si chaque caractère d'un libellé appartient vraisemblablement à une seule écriture, ou à un petit ensemble de combinaisons d'écritures qui apparaissent légitimement ensemble, comme les kanji japonais avec les hiragana. Mélangez des écritures en dehors de cet ensemble autorisé et le navigateur affiche la forme xn-- brute plutôt que de la décoder - le meilleur atout de l'attaque, un domaine qui paraît parfaitement normal, redevient une chaîne manifestement encodée. Firefox applique une vérification comparable, décrite dans l'algorithme d'affichage IDN de Mozilla, et Safari applique sa propre version.
Ce n'est pas une protection complète. Un libellé à écriture mixte construit uniquement à partir de caractères appartenant à une même combinaison autorisée peut encore passer sous la forme d'un nom lisible et trompeur, et la règle est appliquée navigateur par navigateur, sans autorité commune pour décider de ce qui est considéré comme sûr.
Où s'arrête cette protection
La vérification du mélange d'écritures vit dans le code d'affichage de la barre d'adresse du navigateur. Elle ne voyage nulle part ailleurs avec l'URL, et c'est dans cet écart qu'un domaine usurpé fait encore de réels dégâts.
Les clients de messagerie représentent l'exposition la plus importante : un message peut afficher n'importe quel texte d'ancrage sur un lien, quelle que soit la destination, et la plupart des applications de messagerie n'effectuent aucune vérification de sosies. Les applications de chat déplient un lien partagé en une carte d'aperçu construite à partir des métadonnées de la page, et non par un moteur de rendu conscient du punycode. Les codes QR suppriment entièrement l'étape du texte, un écart que nous couvrons dans les codes QR sont-ils sûrs, et les supports imprimés n'ont aucune couche logicielle entre l'oeil et la tromperie.
| Canal | Montre la vraie destination avant d'agir | Exposition typique |
|---|---|---|
| Navigateur de bureau moderne | Généralement, grâce aux règles de mélange d'écritures | Faible pour les navigateurs courants, à jour |
| Client de messagerie | Rarement - le texte d'ancrage peut dire n'importe quoi | Élevée, surtout sur les applications de messagerie mobiles |
| Applications de chat et de messagerie | Rarement - les aperçus de liens utilisent les métadonnées de la page | Élevée, les aperçus dépliés sont identiques |
| Code QR | Non - rien ne s'affiche avant le scan | Élevée, la décision se prend en une fraction de seconde |
| Support imprimé | Jamais - aucun logiciel n'intervient | La plus élevée, aucune vérification technique n'est possible |
Si votre équipe envoie des liens sous un domaine que vos clients reconnaissent déjà, un sosie usurpé dispose de bien moins de marge pour vous imiter de façon convaincante sur tous ces canaux à la fois. Découvrez comment fonctionne un domaine de marque personnalisé sur Elido si vous envoyez encore des liens depuis un domaine partagé ou générique.
Pourquoi un domaine de marque est votre meilleure défense
Une attaque par homographes fonctionne en exploitant la familiarité - elle a besoin d'une marque reconnaissable à contrefaire. Cela ressemble à un argument contre le fait de construire un domaine reconnaissable qui vous soit propre, et c'est exactement l'inverse. Un lien court de marque distinctif que votre audience associe déjà à vous est quelque chose qu'elle peut comparer à un message suspect ; un domaine de raccourcisseur générique ou emprunté donne à un attaquant un modèle que les clients ne peuvent de toute façon pas distinguer du véritable fournisseur, parce qu'aucun des deux ne ressemble à "vous".
Configurer un domaine personnalisé pour vos liens courts signifie que chaque lien que vous envoyez porte un nom que les destinataires reconnaissent, ce qui relève la barre pour quiconque tenterait de le contrefaire. À distinguer du cloaking de liens et du masquage d'URL, un choix délibéré et déclaré de faire passer les liens par votre propre domaine. Une attaque par homographes est le mouvement inverse - dissimuler l'identité de l'attaquant tout en imitant la vôtre - et la défense consiste en la transparence sur le domaine qui est réellement le vôtre.
Les contrôles de registrar qui comptent vraiment
Deux contrôles font l'essentiel du travail réel une fois que vous possédez un domaine qui mérite d'être protégé, et ils opèrent à des niveaux différents de la chaîne.
Le registrar lock est celui du quotidien - un indicateur d'état, souvent affiché sous la forme clientTransferProhibited, qui bloque les demandes de transfert automatisées de routine à l'intérieur du tableau de bord de votre propre registrar. Chaque domaine que vous utilisez activement devrait l'avoir activé ; cela ne coûte rien. Le registry lock se situe un niveau au-dessus, en impliquant directement l'opérateur du registre, de sorte que tout changement, transfert ou suppression nécessite une vérification manuelle hors bande - un appel téléphonique ou une phrase secrète - avant de prendre effet. Cette friction a sa place sur le domaine, ou les deux, où un changement non autorisé serait réellement coûteux, ce qui, pour la plupart des entreprises, signifie au minimum le domaine de marque principal.
Aucun des deux verrous n'empêche quelqu'un d'enregistrer un domaine sosie juste à côté du vôtre. Cela nécessite une surveillance active : observer les nouveaux enregistrements de domaines et les journaux publics de transparence des certificats à la recherche de noms visuellement proches de votre marque, afin de pouvoir le signaler au registrar ou alerter vos clients avant qu'une campagne l'utilisant n'atteigne qui que ce soit.
Ce qu'il faut inclure dans une politique de protection de marque
Si vous possédez un domaine qui vaut la peine d'être usurpé, la section sécurité de votre politique de protection de marque doit être assez précise pour qu'une personne nouvelle dans l'équipe puisse l'exécuter sans avoir à vous demander d'abord.
- Le verrou de transfert registrar sur chaque domaine que possède l'entreprise, avec le registry lock ajouté sur le domaine de marque principal et sur tout ce qui gère les paiements ou les connexions.
- Une cadence récurrente d'analyse des nouveaux enregistrements de domaines et des journaux de transparence des certificats à la recherche de noms visuellement proches de votre marque, et non une vérification ponctuelle.
- L'enregistrement défensif des libellés sosies à plus haut risque et des extensions de premier niveau confusables que vous pouvez justifier, classés par ordre de priorité selon leur proximité avec votre domaine principal.
- Un responsable désigné et un circuit d'escalade pour signaler un domaine sosie découvert à son registrar, ainsi qu'une consigne interne pour que l'équipe support reconnaisse le schéma lorsqu'un client en signale un. La checklist de sécurité pour choisir un fournisseur de liens couvre les contrôles fournisseurs adjacents.
Une méthode de vérification que tout le monde peut suivre
Vous n'avez pas besoin de comprendre le punycode pour vérifier un lien en toute sécurité. Quatre étapes, effectuées dans l'ordre, interceptent presque tout ce sur quoi repose une attaque par homographes.
- Développez d'abord le lien, plutôt que de cliquer directement dessus. Comment voir où mène une URL courte présente les outils pour cela, et le vérificateur de liens d'Elido fait la même chose sans vous demander de faire d'abord confiance à la destination.
- Lisez le domaine enregistrable - la partie immédiatement avant l'extension de premier niveau - plutôt que ce qui apparaît avant. C'est la partie qu'un attaquant doit entièrement contrôler.
- Vérifiez la présence d'un préfixe xn--, que ce soit dans l'URL développée brute ou dans la barre d'adresse de votre navigateur. Si vous en voyez un là où vous attendiez un nom de marque simple, arrêtez-vous et traitez-le comme un sosie jusqu'à preuve du contraire.
- Confirmez le nom figurant sur le certificat du site de destination. Un certificat reflète ce qui a réellement été émis à un propriétaire de domaine, ce qui est plus difficile à falsifier de façon convaincante qu'un libellé affiché.
Aucune de ces étapes ne prend plus de quelques secondes une fois qu'elles sont devenues des habitudes, et vous pouvez enseigner les quatre à un collègue non technique dans le temps qu'il faut pour lire cette section une seule fois.
Une attaque par homographes est un problème d'affichage déguisé en problème de sécurité. Le punycode fait exactement ce pour quoi il a été conçu ; la tromperie se produit dans l'écart entre ce qu'est réellement un domaine et ce qu'un logiciel vous montre à la place. Les navigateurs ont comblé la majeure partie de cet écart pour la barre d'adresse. Partout ailleurs, l'écart reste ouvert, ce qui explique pourquoi développer un lien et lire le domaine enregistrable demeure l'habitude qui fonctionne quel que soit le canal qui a mis le lien devant vous.
À lire aussi sur le blog
- Les raccourcisseurs d'URL sont-ils sûrs ? Comment vérifier un lien court
- Les codes QR sont-ils sûrs ? Le quishing et comment s'en protéger
- La checklist de sécurité du raccourcisseur d'URL
- Configurer des domaines personnalisés pour vos liens courts
- Comment voir où mène une URL courte avant de cliquer
Questions fréquentes
Qu'est-ce qu'une attaque par homographes IDN ?
Une attaque par homographes IDN consiste à enregistrer un domaine en utilisant des caractères d'une autre écriture qui ressemblent, de façon identique ou quasi identique, à ceux d'un domaine réel, si bien qu'un lecteur ne peut pas distinguer les deux à l'oeil nu. Le cas classique remplace une seule lettre latine par un sosie cyrillique ou grec, par exemple le a cyrillique pour le a latin, tandis que tout le reste du domaine reste inchangé. Comme le caractère de substitution a un point de code sous-jacent différent, les deux domaines sont techniquement distincts et peuvent être enregistrés et contrôlés par des propriétaires différents. L'attaque réussit uniquement grâce à l'apparence, ce qui explique pourquoi elle vise des noms de marque reconnaissables et dignes de confiance plutôt que des noms obscurs.
Qu'est-ce que le punycode et pourquoi existe-t-il ?
Le punycode est l'encodage qui transforme les libellés de domaine non-ASCII en une chaîne ASCII que le système de noms de domaine peut stocker et résoudre, défini dans la RFC 3492. Il existe parce que le DNS ne comprend qu'un jeu de caractères ASCII limité, si bien qu'un domaine écrit en cyrillique, en arabe, en chinois, ou avec des lettres latines accentuées, doit être traduit sous cette forme avant de pouvoir être résolu. Le libellé encodé commence toujours par le préfixe xn--, qui indique aux résolveurs et aux navigateurs que ce qui suit est une chaîne encodée en punycode plutôt qu'un nom ASCII simple. Les navigateurs le décodent ensuite dans l'écriture d'origine pour l'affichage, ce qui est une fonctionnalité légitime et nécessaire, et non la faille en elle-même.
Que signifie le préfixe xn-- dans une URL ?
Le préfixe xn-- marque un libellé de domaine comme un ASCII Compatible Encoding, produit par le punycode, signalant que le nom lisible a été traduit à partir de caractères non-ASCII. Tout ce qui suit le préfixe est la forme encodée du libellé d'origine - xn--nvacloud-nbh.com, par exemple, se décode en un domaine qui ressemble à novacloud.com avec une lettre remplacée par un sosie. Voir apparaître la forme xn-- là où vous attendiez un nom de marque simple est exactement le signal que les navigateurs utilisent pour vous avertir, parce que cela signifie que le libellé mélangeait des écritures d'une façon que le navigateur n'a pas jugée sûre pour être affichée sous sa forme lisible. Un domaine sans aucun caractère non-ASCII ne produit jamais de forme xn--, donc en voir une mérite toujours un second regard.
Les navigateurs protègent-ils contre les attaques par homographes ?
Les navigateurs modernes appliquent des règles de mélange d'écritures qui interceptent la plupart des tentatives d'homographes et affichent la forme punycode brute plutôt que la forme trompeuse. Chrome et Firefox vérifient tous deux si les caractères d'un libellé de domaine appartiennent vraisemblablement à une seule écriture ou à un petit ensemble d'écritures couramment utilisées ensemble, et si ce n'est pas le cas, ils affichent la version xn-- plutôt que de la décoder en quelque chose qui pourrait passer pour un nom familier. Cela ferme la porte aux attaques les plus faciles, celles qui utilisent une écriture entière, en empêchant qu'elles s'affichent comme des imposteurs convaincants, même si les attaquants peuvent encore trouver, à l'intérieur des ensembles autorisés, des caractères visuellement confusables avec des lettres latines. La protection se limite aussi strictement à la barre d'adresse du navigateur - rien d'autre dans la chaîne ne l'hérite automatiquement.
Comment savoir si un lien est un domaine sosie avant de cliquer dessus ?
Développez d'abord le lien pour voir la destination complète plutôt qu'une version courte ou tronquée, puis lisez le domaine enregistrable plutôt que ce qui le précède. Si la barre d'adresse ou l'outil de développement affiche un préfixe xn-- là où vous attendiez un nom de marque simple, considérez-le comme un domaine sosie jusqu'à preuve du contraire. Confirmer le nom figurant sur le certificat du site de destination est une dernière vérification utile, puisqu'un certificat reflète ce qui a réellement été émis plutôt que ce qui est simplement affiché. Rien de tout cela ne nécessite un logiciel particulier - juste l'habitude de le faire avant de saisir un mot de passe ou un numéro de carte.
Qu'est-ce que le registry lock et mon domaine en a-t-il besoin ?
Le registry lock est un contrôle établi au niveau du registre du domaine qui bloque toute modification, tout transfert ou toute suppression du domaine tant qu'il n'a pas été vérifié manuellement hors bande, typiquement par téléphone ou via une phrase secrète, ce qui empêche même un compte de registrar compromis de déplacer le domaine. C'est une garantie plus forte que le registrar lock, plus courant, qui ne fait qu'empêcher les transferts automatiques de routine à l'intérieur de votre propre tableau de bord de registrar. Le registry lock vaut son coût annuel modeste pour tout domaine dont l'indisponibilité ou le détournement serait coûteux, ce qui, pour la plupart des entreprises, signifie au minimum le domaine de marque principal. Il n'empêchera pas quelqu'un d'enregistrer un domaine qui ressemble au vôtre juste à côté - c'est un problème distinct, résolu par la surveillance, pas par le verrouillage.
Essayer Elido
Collez une URL, obtenez un lien court
Sans inscription. Lien actif 30 jours. Inscrivez-vous pour le garder pour toujours.
Gratuit, sans inscription · 2 par jour