SMTPUTF8, adresses e-mail Unicode, risques de sécurité et compatibilité en pratique.
La validation d’une adresse e-mail semble simple. L’utilisateur saisit une adresse, l’application en vérifie le format et l’inscription se poursuit.
Mais que se passe-t-il si quelqu’un s’inscrit avec müller@example.com ?
Nous avons récemment discuté de la possibilité d’autoriser les caractères Unicode dans la partie locale des adresses e-mail lors de l’inscription - la partie qui précède le symbole @.
À première vue, la réponse semble simple. Si une adresse e-mail est autorisée par des normes établies, pourquoi la refuser ?
Pourtant, prendre en charge une adresse e-mail ne se limite pas à l’accepter lors de l’inscription.
La compatibilité de l’acheminement des e-mails, les processus d’authentification, les intégrations avec des services tiers et les considérations de sécurité influencent tous cette décision.
Qu’est-ce que SMTPUTF8 ?
Traditionnellement, les adresses e-mail utilisent principalement des caractères ASCII. L’extension SMTPUTF8, définie dans la RFC 6531, permet des adresses e-mail internationalisées contenant des caractères non ASCII.
Elle autorise ainsi des adresses telles que :
müller@example.comδοκιμή@example.com用户@example.com
Il existe une distinction importante entre les noms de domaine internationalisés et les caractères Unicode dans la partie locale.
| Adresse e-mail | Caractéristiques | Compatibilité |
|---|---|---|
john@example.com |
Partie locale et domaine en ASCII | Largement pris en charge |
user@bücher.example |
Domaine Unicode | Peut utiliser l’encodage Punycode |
müller@example.com |
Partie locale Unicode | Nécessite SMTPUTF8 |
δοκιμή@example.com |
Partie locale en grec | Nécessite SMTPUTF8 |
Les domaines internationalisés peuvent être représentés en Punycode, un encodage compatible avec ASCII.
Cette approche ne permet toutefois pas de convertir les parties locales Unicode en adresses e-mail ASCII équivalentes.
La prise en charge de SMTPUTF8 est nécessaire pour transporter ces adresses.
Et c’est là que la compatibilité devient un défi.
Le problème de compatibilité avec AWS SES
Amazon Simple Email Service (AWS SES) est largement utilisé pour les e-mails transactionnels, notamment les confirmations d’inscription, les réinitialisations de mot de passe et les notifications de compte.
Cependant, AWS SES ne prend pas en charge l’extension SMTPUTF8.
Selon sa documentation, les chaînes représentant les adresses e-mail doivent être en ASCII 7 bits. Les domaines internationalisés peuvent utiliser Punycode, mais les parties locales Unicode ne sont pas prises en charge.
Prenons une application qui accepte :
müller@example.com
L’application peut valider l’adresse et l’enregistrer dans une base de données compatible avec UTF-8.
Mais lorsqu’elle tente d’envoyer un e-mail de vérification via AWS SES, la requête ne peut pas utiliser cette adresse de destinataire.
Le processus d’inscription ne fonctionne alors plus correctement.
L’application accepte une adresse que son infrastructure de messagerie ne peut pas prendre en charge.
Cet exemple montre pourquoi les règles de validation doivent tenir compte des capacités des dépendances externes.
Sécurité : quand des caractères différents semblent identiques
La compatibilité n’est pas le seul enjeu.
Unicode introduit des considérations de sécurité supplémentaires, en particulier lorsque des caractères visuellement similaires appartiennent à des systèmes d’écriture différents.
Par exemple, la lettre latine o et la lettre cyrillique о semblent presque identiques dans de nombreuses polices.
Ce sont pourtant des caractères différents, avec des points de code Unicode distincts.
Considérons ces deux adresses :
| Adresse e-mail | Caractère utilisé | Unicode |
|---|---|---|
support@example.com |
o latin |
U+006F |
suppоrt@example.com |
о cyrillique |
U+043E |
Dans la seconde adresse, la lettre qui ressemble à un "o" est en réalité cyrillique.
Pour une personne, ces adresses peuvent sembler identiques.
Pour un ordinateur, elles contiennent des séquences de caractères différentes.
Cela crée des possibilités d’attaques par homographes, dans lesquelles des caractères visuellement similaires servent à usurper des identités de confiance.
Les risques potentiels comprennent :
- Usurpation d’identité : Un attaquant qui contrôle une adresse ressemblante pourrait tenter de se faire passer pour un utilisateur légitime.
- Confusion entre comptes : Les applications qui affichent les adresses e-mail comme identifiants utilisateur peuvent rendre difficile la distinction entre des comptes visuellement similaires.
- Erreurs de contrôle d’accès : Les systèmes reposant sur des comparaisons de chaînes mal conçues ou des listes d’autorisation gérées manuellement peuvent traiter incorrectement des adresses visuellement similaires.
- Ingénierie sociale : Des adresses ressemblantes peuvent tromper les utilisateurs, les administrateurs ou les équipes d’assistance.
Ces problèmes ne signifient pas que les adresses Unicode sont intrinsèquement malveillantes.
Une adresse ressemblante ne reçoit pas non plus automatiquement les messages destinés à une autre boîte aux lettres. L’attaquant doit contrôler l’adresse qu’il utilise.
Les risques deviennent toutefois particulièrement importants lorsque les adresses e-mail servent d’identifiants visibles ou interviennent dans des décisions sensibles pour la sécurité.
La RFC 6530 traite explicitement des caractères visuellement confondables et des attaques par homographes dans les adresses e-mail internationalisées.
Pourquoi cela compte pour l’inscription et l’authentification
Les adresses e-mail servent rarement uniquement à l’inscription initiale.
Elles interviennent souvent dans des processus critiques de l’application :
- Inscription et vérification des comptes.
- Authentification des utilisateurs et identification des comptes.
- Récupération des mots de passe.
- Notifications de sécurité.
- Administration des comptes.
Un échec dans l’un de ces processus peut entraîner des problèmes d’utilisation ou de sécurité.
La vérification d’une adresse e-mail confirme qu’une personne peut y recevoir des messages. Elle ne prouve pas que cette adresse se distingue visuellement de celle d’un autre utilisateur ni que son propriétaire est digne de confiance.
Les applications doivent donc éviter de prendre des décisions d’autorisation en fonction de l’apparence d’une adresse e-mail aux yeux d’une personne chargée de la vérifier.
ASCII uniquement ou SMTPUTF8 : comparaison des approches
Le choix de prendre en charge les parties locales Unicode implique plusieurs compromis.
| Critère | Parties locales en ASCII uniquement | Prise en charge de SMTPUTF8 |
|---|---|---|
| Compatibilité de la messagerie | Prise en charge étendue | Dépend de l’infrastructure |
| Internationalisation | Plus restrictive | Plus inclusive |
| Complexité de mise en œuvre | Généralement plus faible | Exigences supplémentaires |
| Exposition aux homographes | Réduite dans les parties locales | Nécessite une attention supplémentaire |
| Intégrations avec des services tiers | Meilleure compatibilité | Vérification nécessaire |
| Exigences de test | Plus simples | Davantage de cas limites |
Aucune de ces approches n’est universellement correcte.
Pour les applications qui dépendent de fournisseurs ne prenant pas en charge SMTPUTF8, restreindre les caractères Unicode dans la partie locale peut être un choix d’ingénierie raisonnable.
Pour les applications destinées à un public international, la prise en charge de SMTPUTF8 peut constituer une exigence importante.
La décision doit tenir compte des besoins du produit, des capacités de l’infrastructure et des exigences de sécurité.
Recommandations pratiques pour les développeurs
Avant d’activer SMTPUTF8, les équipes de développement doivent examiner plusieurs points.
1. Vérifier la compatibilité de l’infrastructure
Confirmez que les fournisseurs de messagerie, les services d’authentification et les intégrations avec des services tiers prennent en charge les adresses e-mail internationalisées.
2. Valider l’ensemble du processus d’inscription
Ne supposez pas qu’une validation syntaxique réussie garantit la bonne livraison des e-mails.
Testez les e-mails de vérification, les réinitialisations de mot de passe et les autres communications critiques.
3. Envisager la détection des caractères Unicode visuellement confondables
La norme Unicode Technical Standard #39 fournit des mécanismes permettant d’identifier les caractères visuellement confondables et les identifiants mêlant plusieurs systèmes d’écriture.
Ces mécanismes peuvent aider les applications à signaler les adresses suspectes pour un examen supplémentaire.
Toutefois, rejeter automatiquement toutes les adresses mêlant plusieurs systèmes d’écriture peut exclure inutilement des utilisateurs légitimes.
4. Traiter la normalisation Unicode avec précaution
La normalisation Unicode peut résoudre certaines différences de représentation des caractères, mais elle n’élimine pas automatiquement les caractères visuellement confondables.
Le o latin et le о cyrillique, par exemple, restent distincts.
Les applications doivent éviter de remplacer, de convertir en minuscules ou de transformer aveuglément les parties locales des adresses e-mail, car l’interprétation de la boîte aux lettres dépend du fournisseur destinataire.
5. Séparer les identités d’authentification
Utilisez des identifiants utilisateur internes stables pour les autorisations et les relations entre comptes, plutôt que de traiter l’adresse e-mail affichée comme une identité de confiance.
6. Tester les cas limites sensibles pour la sécurité
Incluez des adresses visuellement similaires, différentes représentations Unicode et des adresses internationalisées dans les tests d’intégration et de sécurité.
Questions fréquentes
Les adresses e-mail Unicode sont-elles valides ?
Oui. Les normes de messagerie internationalisée autorisent les caractères Unicode dans les adresses e-mail sous certaines conditions. Toutefois, la validité syntaxique ne garantit pas que tous les fournisseurs de messagerie puissent les traiter.
AWS SES prend-il en charge SMTPUTF8 ?
Non. La documentation AWS SES indique que SMTPUTF8 n’est pas pris en charge. Les adresses e-mail doivent utiliser ASCII, même si les domaines internationalisés peuvent être représentés en Punycode.
Les adresses e-mail Unicode présentent-elles un risque de sécurité ?
Pas intrinsèquement. Cependant, les caractères visuellement confondables peuvent créer des risques d’usurpation et de gestion des identités si les applications ne les traitent pas correctement.
Les applications doivent-elles refuser les adresses e-mail Unicode ?
Pas automatiquement. La décision doit tenir compte des exigences d’internationalisation, de la compatibilité de l’infrastructure et de mesures de sécurité appropriées.
Pour conclure
La validation des adresses e-mail est souvent considérée comme un simple détail de mise en œuvre.
En réalité, elle relie la logique de l’application, les services externes, l’expérience utilisateur et la sécurité.
SMTPUTF8 montre comment une norme établie peut poser des difficultés pratiques lorsque sa prise en charge par l’infrastructure est inégale.
Les caractères Unicode ressemblants ajoutent un autre enjeu : deux adresses qui semblent identiques aux utilisateurs peuvent représenter des identités différentes.
L’objectif n’est pas simplement d’accepter une saisie techniquement valide, mais de veiller à ce que l’application puisse la traiter de manière sûre et fiable tout au long du parcours utilisateur.
Références
- RFC 6531 - Extension SMTP pour la messagerie internationalisée (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)
- RFC 6530 - Cadre de la messagerie internationalisée, considérations de sécurité (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)
- Unicode Technical Standard #39 - Mécanismes de sécurité Unicode (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)
- Amazon SES - Documentation de l’API SendEmail (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)
