La lettre latine « a » et la lettre cyrillique « а » s’affichent de façon rigoureusement identique dans la plupart des polices de caractères courantes. Pourtant, ce sont deux points de code Unicode distincts, deux caractères différents pour tout programme qui les compare. Cette différence invisible à l’œil nu, mais parfaitement mesurable par une machine, est le principe même de l’attaque par homoglyphes appliquée aux noms de domaine internationalisés.
Définition : une confusion entre apparence et identité
Un nom de domaine internationalisé, ou IDN, permet d’enregistrer un domaine contenant des caractères hors de l’alphabet latin de base : accents, caractères cyrilliques, grecs, ou d’autres systèmes d’écriture. Le système de résolution DNS ne comprend nativement que l’ASCII, ces domaines sont donc encodés en Punycode, une représentation ASCII reversible qui commence toujours par le préfixe xn--. Un domaine composé uniquement de caractères cyrilliques visuellement proches de lettres latines peut ainsi produire une chaîne encodée totalement différente de l’originale qu’il imite.
Fonctionnement interne : où la comparaison de chaîne échoue
Un code de validation qui compare simplement deux chaînes de caractères, par exemple pour vérifier qu’une adresse expéditeur appartient bien à un domaine de confiance, travaille sur la représentation textuelle brute reçue par le serveur. Si cette représentation a déjà été décodée depuis sa forme Punycode par une bibliothèque intermédiaire avant validation, la comparaison porte sur des caractères Unicode qui peuvent tromper l’œil d’un développeur relisant un journal, mais pas la machine elle-même, qui les distingue correctement bit à bit.
Le vrai risque apparaît quand la validation repose sur un affichage plutôt que sur une comparaison programmatique stricte : un administrateur qui approuve manuellement un domaine expéditeur en le lisant à l’écran peut valider, sans le savoir, un domaine homoglyphe qui ne correspond pas du tout au domaine légitime qu’il croit reconnaître.
Cas d’usage : où ce risque se manifeste concrètement
- Une liste blanche de domaines expéditeurs autorisés à envoyer des notifications vers une extension WordPress, si elle est alimentée par une interface d’administration où l’opérateur copie-colle ou retape un nom de domaine à l’œil.
- Un champ de saisie d’adresse électronique où le domaine est comparé à une liste de fournisseurs de confiance avant d’accorder un traitement particulier, sans normalisation préalable.
- Un lien affiché dans un courriel de notification, où le domaine visible ne correspond pas au domaine réellement résolu par le navigateur du destinataire.
Pièges à éviter dans une validation robuste
Une validation fiable doit toujours travailler sur la forme Punycode ASCII du domaine, jamais sur sa représentation décodée. En PHP, la fonction native idn_to_ascii(), fournie par l’extension Intl, convertit un domaine internationalisé vers sa forme ASCII canonique. Comparer deux domaines après ce passage par idn_to_ascii() élimine l’ambiguïté visuelle, puisque la comparaison finale porte sur des chaînes ASCII strictement identiques ou différentes, sans place pour l’homoglyphe.
function domaine_est_autorise(string $domaine_saisi, array $domaines_autorises): bool
{
$forme_ascii = idn_to_ascii($domaine_saisi, IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46);
if ($forme_ascii === false) {
return false;
}
return in_array($forme_ascii, $domaines_autorises, true);
}
Une liste blanche de domaines n’a de valeur que si elle compare des formes canoniques identiques, jamais des apparences à l’écran.
En résumé
L’attaque par homoglyphes IDN ne casse aucun mécanisme de sécurité au sens strict : elle exploite une confusion entre ce qu’un humain voit et ce qu’une machine compare. Toute validation de domaine qui s’appuie, même partiellement, sur une lecture visuelle plutôt que sur une comparaison de forme canonique ASCII reste exposée à ce type de tromperie, quelle que soit par ailleurs la rigueur du reste du système.
