Homograph attack : identifier, comprendre et se protéger

Qu'est-ce qu'une homograph attack ?

C’est une technique qui abuse de caractères visuellement similaires (confusables) pour faire passer un texte malveillant pour un texte légitime.

Voici les principaux éléments exploités par une homograph attack :

1 Confusables Unicode (lettres visuellement identiques)

Substitutions discrètes qui imitent l’alphabet latin.

Latin a vs cyrillique а (U+0061 vs U+0430)

Latin e vs cyrillique е (U+0065 vs U+0435)

Latin o vs cyrillique о (U+006F vs U+043E)

Latin p vs cyrillique р (U+0070 vs U+0440)

2 Noms de domaine IDN et Punycode

Des labels internationalisés encodés en ASCII via Punycode (xn--...).

раypal.com → xn--pypal-4ve.com (lettres cyrilliques)

аррle.com → xn--pple-7cd.com (p et a cyrilliques)

gооgle.com → xn--ggle-qmc.com (o cyrilliques)

Mixed-script labels: interdit par de nombreux registrars, mais pas partout

3 Identifiants d’applications et contenus

Usernames, noms de packages, modules, dépôts, commandes.

packaɡe vs package (ɡ U+0261)

nu11 vs null (1 vs l)

1О0 vs 100 (О U+041E lettre cyrillique)

Рython vs Python (Р U+0420)

4 Marques techniques et contrôles directionnels

Bidi, tirets conditionnels et autres marques influençant l'affichage.

LRM, RLM, LRE, RLE, RLO, PDF — contrôles bidirectionnels (Trojan Source)

Soft Hyphen (U+00AD) — coupure discrète en plein mot

ZWSP (U+200B) — séparation à largeur zéro

NBSP (U+00A0) — espace insécable ressemblant à un espace simple

Scénarios d'attaque fréquents

Liens de phishing qui imitent un domaine légitime

Un domaine IDN ressemble à la marque d'origine mais pointe vers une infrastructure malveillante.

Packages malveillants dans les registries

Un nom de module quasi identique (homographe) remplace l'original lors d’un copier-coller.

Filtrage et validation insuffisants

Une validation accepte des confusables, mélange de scripts ou des marques Bidi non prévues.

Regex naïves et jeux de caractères limités

Selon le moteur, \w/\b ignorent des scripts non-latins ou des contrôles directionnels.

Exemple typique :

# Deux chaînes d'apparence identique, mais différentes

string1 = "domain.com"

string2 = "domаin.com" # contient а cyrillique U+0430

assert string1 == string2 # ❌ Échec

Signaux d'alerte à surveiller

🚨 Indices concrets

!

Un diff git montre des noms quasi identiques, mais la comparaison échoue

!

Un lien “connu” ouvre un site dont le certificat n’appartient pas à la marque attendue

!

Une variable ou un package a le même rendu visuel mais casse l’intégration

!

En déplaçant le curseur, l’éditeur “accroche” une zone invisible (Bidi, ZWSP)

!

Un domaine collé dans le terminal résout vers une IP inattendue

Comment les détecter

✨ Solution recommandée : Clean ASCII

Clean ASCII met en évidence les confusables Unicode, les marques Bidi et les caractères non ASCII, et aide à diagnostiquer les homograph attack sur vos textes, identifiants et domaines.

✅ Détection automatique

Confusables, Bidi (RLO/RLE/LRM…), NBSP/ZWSP, caractères de contrôle

📊 Analyse complète

Scripts utilisés, positions exactes, décodage Punycode/IDN, suggestions

🧹 Nettoyage automatique

Remplacements sûrs vers ASCII ou neutralisation des contrôles

💾 Export propre

Texte nettoyé prêt à intégrer, avec rapport d’actions

🔍 Détecter les homographes

Autres méthodes de détection

Affichage dans l'éditeur

✓ Activez l’affichage des caractères invisibles et des contrôles (whitespace, Bidi)

✓ Installez un linter qui surligne confusables et mélange de scripts

En ligne de commande (Unix)

# Décoder/afficher un domaine IDN (Punycode)

idn2 "domаin.com"

# Repérer des octets non ASCII

grep -P "[^\x00-\x7F]" fichier.txt

# Voir les caractères de contrôle et Bidi

cat -A fichier.txt

# Inspecter les codes hexadécimaux

hexdump -C fichier.txt

En code

JavaScript

/[\p{Script=Cyrillic}\p{Script=Greek}]/u.test(str) || /[\u200B-\u200F\u202A-\u202E]/.test(str)

Python

import idna; idna.encode(hostname).decode()

Excel / Google Sheets

CODE(MID(cellule;position;1))

Réduction du risque et prévention

🚀 Solution rapide avec Clean ASCII

Avant de développer des filtres complexes, utilisez Clean ASCII pour repérer et neutraliser immédiatement les confusables et marques potentiellement utilisées dans une homograph attack.

✓ Détection automatique

✓ Nettoyage intelligent

✓ Export immédiat

Analyser et nettoyer maintenant

Méthodes techniques avancées

🔧 Normaliser

✓ Utilisez Unicode NFC/NFKC pour homogénéiser les formes

✓ Convertissez systématiquement les domaines IDN en Punycode avant comparaison/stockage

✓ Interdisez le mélange de scripts dans un même identifiant (politique “single-script”)

🧹 Filtrer

✓ Écrivez des fonctions skeleton() qui mappent les confusables vers ASCII

✓ Remplacez les lettres suspectes (ex: а/е/о cyrilliques) par leurs équivalents latins

✓ Bloquez les contrôles Bidi hors cas légitimes (RLO/RLE/LRO/PDF)

⚙️ Automatiser

✓ Hooks pre-commit pour refuser confusables, Bidi et labels IDN non conformes

✓ Tests de sanitation sur les inputs utilisateurs (IDN → Punycode, contrôle de script)

✓ Linting en CI pour détecter confusables et caractères hors politique

Checklist rapide

Décodage/encodage systématique IDN ⇄ Punycode pour les domaines

Politique interdisant le mélange de scripts dans un identifiant

Linter qui signale confusables, Bidi et caractères suspects

Fonctions de “skeleton”/normalisation Unicode (NFC/NFKC)

Tests automatisés sur URLs, usernames et noms de packages

Sensibilisation des équipes aux confusables Unicode et domaines IDN

Conclusion

Les homograph attack tirent parti de détails typographiques pour créer la confusion. Les ignorer, c’est laisser une porte d’entrée facile au phishing et à l’usurpation.

Détectez les confusables, appliquez une normalisation cohérente, imposez une politique de scripts stricte : vous neutraliserez l’essentiel des attaques par homographie.

Homograph attack : comprendre et se protéger