Les codeurs conquièrent la sécurité : série Share & Learn - Injection d'en-tête d'e-mail

De nos jours, il est courant que les sites Web et les applications permettent aux utilisateurs d'envoyer des commentaires, des rappels de rendez-vous et diverses autres informations via une application par courrier électronique. Normalement, ce processus est relativement bénin et la plupart des gens n'y pensent même pas en termes de risque de sécurité potentiel.

Cependant, comme tout autre élément de conception permettant la saisie par l'utilisateur, s'ils ne sont pas correctement configurés, ces fonctionnalités apparemment sans importance peuvent être manipulées par des utilisateurs malveillants à des fins malveillantes. Il suffit de donner à l'utilisateur la possibilité de saisir du code dans le champ de saisie qui est ensuite traité par erreur par le serveur. Soudainement, une application de messagerie peut devenir une arme.

Dans cet épisode, nous allons apprendre :

• Comment les attaquants peuvent déclencher une injection d'en-tête d'e-mail
• Pourquoi les injections d'en-têtes d'e-mail sont dangereuses
• Techniques permettant de corriger cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection d'en-tête d'e-mail ?

Bien qu'elle ne soit pas souvent considérée comme programmable, la plupart des applications de contact par courrier électronique ou des fonctionnalités intégrées à des sites Web ou à des applications peuvent accepter des entrées qui modifient la nature de la requête. Normalement, le serveur le fait automatiquement une fois qu'un utilisateur a saisi ses informations, telles que son adresse e-mail, dans le champ du contrat. Le programme configure ensuite le message, ajoute les destinataires appropriés et envoie le message à l'aide de son serveur de messagerie par défaut.

Une requête POST par e-mail typique peut ressembler à ceci :

POST /contact.php HTTP/1.1
Hébergeur : www.example.com

Et générez un code qui ressemble à ceci une fois qu'un utilisateur a saisi ses informations :

Name=RealName&ReplyTo= RealName@ValidServer.com &message=Votre rappel de rendez-vous

Le problème survient lorsque les pirates informatiques commencent à injecter du code dans le processus au lieu de se contenter de leurs informations de contact. Cette attaque n'est pas sans rappeler une attaque de type injection SQL, mais elle a été lancée contre l'application de messagerie. Voici un exemple de requête manipulée qui enverrait plutôt du spam depuis votre application à un utilisateur ciblé :

name=FakeName\nbcc : SpammedVictim@TargetAddress.com &ReplyTo= FakeName@ValidServer.com &message=Message spammé

Pourquoi l'injection d'en-tête d'e-mail est-elle dangereuse ?

En fonction des compétences de l'utilisateur malveillant et de ses intentions, les attaques par injection d'en-tête d'e-mail peuvent être simplement ennuyeuses ou très dangereuses en termes de gravité. Au bas de l'échelle de gravité, ils pourraient être en mesure d'insérer leurs coordonnées dans le champ BCC d'un message sortant envoyé vers une boîte aux lettres secrète ou non divulguée de votre entreprise, le révélant ainsi à un pirate informatique.

Plus inquiétant encore, cela pourrait leur permettre de contrôler complètement votre serveur de messagerie pour envoyer du spam, du phishing ou d'autres e-mails d'attaque depuis votre organisation. Ils n'auraient pas besoin d'essayer de simuler le fait que l'e-mail provient de vos serveurs internes, car il proviendrait en fait de là. Et si vous ne surveillez pas cette activité, ils peuvent même automatiser le processus en envoyant des centaines ou des milliers de courriels via les serveurs de votre organisation, de manière à donner l'impression que vous êtes à l'origine de cette activité.

Élimination du problème d'injection d'en-tête d'e-mail

Comme pour Injection SQL et d'autres attaques de cette nature, la clé pour éliminer la possibilité qu'un utilisateur malveillant exploite une vulnérabilité d'en-tête d'e-mail est de ne jamais se fier aux entrées de l'utilisateur. Si un utilisateur est capable de saisir des informations, même si cela semble être un processus banal, comme la saisie de son adresse e-mail, vous devez vous attendre au pire. Ou du moins, supposez que le pire est possible.

La validation des entrées doit être effectuée pour tous les paramètres, y compris lors de l'ajout d'une capacité de contact par e-mail à une application ou à un site Web. La liste blanche peut être utilisée pour activer spécifiquement les processus et les champs que vous considérez comme valides, tout en refusant tout le reste. En fait, la plupart des frameworks disposent de bibliothèques qui peuvent être utilisées pour aider à verrouiller les fonctions uniquement à celles qui sont nécessaires. Cela empêchera le code ou les commandes saisis par des utilisateurs malveillants d'être reconnus et traités par vos serveurs.

Plus d'informations sur les injections d'en-têtes d'e-mail

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de injections d'en-têtes d'e-mails. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce au démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Blog Secure Code Warrior.

Vous pensez être prêt à trouver et à corriger une injection d'e-mail dès maintenant ? Rendez-vous sur la plateforme et testez vos compétences : [Commencez ici]