
Les adresses email, vous connaissez ?
Hello,
Si tu t’es aventuré ici, c’est que tu penses tout savoir des adresses email. Mais en es-tu sûr ?
Dans cet article, on va parler de la syntaxe des adresses emails, et on va essayer de définir ce qui est valide et ce qui ne l’est pas.
Commençons par le plus simple. Pour toi, une adresse email c’est simplement:
caractères Majuscule ou minuscule avec un tiret ou un point @ nom de domaine . tld ? et bien non !
Bon nombre de personnes se contentent de cette définition mais elle est fausse !
Je suis sûr qu’en tout bon pentesteur, CTF player ou infosec addict que tu es, tu connais forcément l’astuce du “+”. Mais oui tu sais, cette astuce dont tu as entendu parler qui te permet de savoir depuis quel site pourri tes adresses emails fuitent en rajoutant des tags derrière un “+” !
Pour tous les exemples que je vais citer dans cet article, on va imaginer que j’ai créé une boite mail unique :
sicalabe@gmail.com
Exemple: Je compte créer un compte sur wish, je vais donc utiliser un email spécifique (email poubelle) pour savoir si wish revend mes infos. Mais j’ai pas envie de créer une adresse email à chaque fois ! j’utilise donc un tag:
sicalabe+wish@gmail.com
Si on décortique, on a “sicalabe” qui est le nom de ma boite, ou le “local-part” d’après la RFC 822 de 1982 , puis on a un signe “+” qui délimite un tag dans la “local-part” de l’email, enfin on a “wish” qui est un tag et gmail.com le domaine.
Si on envoie un mail à sicalabe+wish@gmail.com, le mail sera envoyé sur la boite sicalabe@gmail.com mais l’adresse réelle du header mail “RCPT to:” sera sicalabe+wish@gmail.com !
Bon, voilà où s’arrêtait ma culture personnelle sur les adresses email.
Mais il faut savoir qu’un email, c’est beaucoup (beaucoup) plus complexe que ça. Et il existe des syntaxes d’email valides, qui constituent une vraie menace potentielle pour un système. Il faut aussi savoir que la partie “local-part” d’un email est limitée a 64 caractères.
Pour la suite du document, je vais m’appuyer sur les RFCs 5322 5321 et 822, et la page Wikipedia dédiée aux adresses email.
Les commentaires
Vous saviez qu’une adresse email peut avoir des commentaires ?
Exemple d’emails valides:
(commentaire)sicalabe@gmail.com
sicalabe(commentaire)@gmail.com
Ces adresses sont automatiquement transformées en sicalabe@gmail.com lors de l’envoi du mail, mais si vous enregistrez un compte sicalabe(site)@gmail.com, dans la plus grande majorité des cas vous devrez utiliser l’email AVEC commentaire pour vous connecter !
Dans quel cas c’est utile ? Imaginez, votre mot de passe fuite sur internet (😲) et vous avez utilisé plusieurs fois ce mot de passe ? et bien si vous prenez l’habitude de créer des comptes avec des commentaires dans les emails, personne pourra se connecter à votre compte ! C’est une espèce de 2eme mot de passe si le service ne vous propose pas de 2FA 😉 Bon attention quand même, ça remplace pas une politique de mots de passes robustes et le vrai 2FA hein !
Les IPs
Vous saviez que le domaine d’une adresse mail, ça peut aussi être une IP ?
les exemples suivants sont tous valides en théorie:
sicalabe@127.0.0.1
sicalabe@[127.0.0.1]
sicalabe@[IPv6:2001:db8::1]
à savoir que certains domaines sont spécifiquement non résolus par les serveurs SMTP pour que les emails soient juste des exemples:
sicalabe@domain.example
sicalabe@example.com|net|org
sicalabe@domain.invalid
Enfin, tout comme pour la local-part, les commentaires dans le nom de domaine sont théoriquement autorisés (mais rarement acceptés par les sites, car dans une majorité des cas, le site tentera de faire une résolution DNS du domaine avant de valider l’email). Chez Google c’est pas autorisé en tout cas:
Chez Hackerone non plus:
Exemples valides en théorie:
sicalabe@(commentaire)gmail.com
sicalabe@gmail.com(commentaire)
Les caractères spéciaux
On arrive dans la partie qui m’à incité a créer cet article. Une adresse email peut se composer en réalité d’une quantité de caractères spéciaux assez affolante, en voici la liste complète:
! $ & * - = \^ ` | ~ # % ' + / ? _ { } .
Mais aussi dans certaines circonstances (détaillées dans la partie Misc):
@ " espace < > : ; ,
Tous ces caractères spéciaux sont totalement valides dans les adresses email, ce qui donne des emails-payloads vraiment très intéressants. En voici un qui me sert relativement souvent:
sicalabe+${7*7}{{7*7}}`id`|'or''='@gmail.com
Cette adresse mail peut tester des SSTI, des injections de code et des SQLI en même temps ! Dingue non ?
Il est évident que certains sites vont appliquer des filtres d’emails (souvent en javascript), mais avec ce payload, tu fournis un email complètement valide au yeux du serveur SMTP pour recevoir tes petits emails de tests, tout en testant la robustesse du code front&back de l’application.
Misc
Dans cette section finale, on va parler des syntaxes qui me font péter des câbles.
Comme pour beaucoup de choses, mettre une chaîne de caractères entre guillemets permet de l’escape. Les adresses email ne dérogent pas à la règle.
Exemples d’emails (avec description si nécessaire), rouge = invalides, vert = valides. Pour les invalides, c’est souvent car il faut escape le caractère incriminé:
sicalabe@gmail.com -> classique
"sicalabe"@gmail.com == sicalabe(test)@gmail.com == (test)sicalabe@gmail.com == sicalabe@gmail.com
pour le SMTP mais généralement sont strictement différents pour le système de login.
sica.labe@gmail.com
sica..labe@gmail.com
-> double points interdits
"sica..labe"@gmail.com
sica@labe@gmail.com
-> double @ interdit
sica\@labe@gmail.com == "sica@labe"@gmail.com
sica labe@gmail.com
-> espace interdit
sica\ labe@gmail.com
"sica labe"@gmail.com
sica"labe"@gmail.com
-> si on commence à mettre entre guillemets, c’est tout qui doit l’être
"sica"."labe"@gmail.com
sica.\labe@gmail.com
-> le backslash doit servir à escape un caractère interdit.
sica.\\labe@gmail.com
->== sica.\lab@gmail.com
une fois le “\” échappé. si jamais on insère \\r\\n, il est possible que le système les interprète en tant que \r\n (CRLF) ailleurs dans le code.
sica=labe@gmail.com
même l’email
" "@gmail.com
est valide !D’après les RFCs 6530 6531 et 6532, ces adresses sont aussi valides:
fromagère.pelée@gmail.com
-> souviens toi que dans la RFC de 1982 seuls les caractères a-z et A-Z sont autorisés pour les lettresδοκιμή@παράδειγμα.δοκιμή
我買@屋企.香港
संपर्क@डाटामेल.भारतारत
Allez on se lâche un peu?
"sica.(),:;<>[]\".labe.\"sica@\ \"labe\".sicalabe"@gmail.com
Il y a aussi des syntaxes particulières qui seront interprétées par des systèmes:
mailhost!sicalabe@gmail.com
-> c’est une route “bangifiée” utilisée par les mailers uucp (Unix-to-Unix Copy)
sicalabe%gmail.com@domaine.org
-> c’est une route vers l’email “sicalabe@gmail.com” via le domaine “domaine.org”
En somme, c’est dingue le champ des possibles qui vient de s’ouvrir devant moi. Et toi, t’as appris des choses ?
Des bisous 🙂
Sicarius
Commentaires
Pour l’heure, Microsoft 365 ne gère déjà pas le « + » (tag), alors le reste des spécifications… laisse rêveur…
Après si microsoft était un exemple de propreté en applications des standards … ca se saurait 🙂