Les développeurs à la conquête de la sécurité : Série Partage & Apprentissage - Injection d'en-tête d'e-mail

Il est aujourd'hui courant que les sites web et les applications permettent aux utilisateurs d'envoyer des commentaires, des rappels de rendez-vous et diverses autres informations par e-mail. Ce processus est généralement assez bénin, et la plupart des gens ne le perçoivent pas comme un risque de sécurité potentiel.

Cependant, comme tout autre élément de conception acceptant des entrées utilisateur, ces fonctionnalités apparemment anodines peuvent être détournées par des utilisateurs malveillants à des fins malfaisantes si elles ne sont pas correctement configurées. Il suffit de donner à l'utilisateur la possibilité de saisir du code dans un champ de saisie qui sera ensuite traité par erreur par le serveur. Soudainement, une application de messagerie peut devenir une arme.

Dans cet épisode, nous apprendrons :

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

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

Bien qu'on ne les considère pas souvent comme programmables, la plupart des applications ou fonctionnalités de contact intégrées aux sites web peuvent accepter des entrées qui modifient la nature de la requête. Cela se fait normalement automatiquement par le serveur après qu'un utilisateur a saisi ses informations, comme son adresse e-mail, dans le champ de contact. Le programme configure alors le message, ajoute les destinataires appropriés et envoie le message via son serveur de messagerie par défaut.

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

POST /contact.php HTTP/1.1
Host: www.example.com

Et générer un code qui ressemble à ceci après que l'utilisateur a saisi ses informations :

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

Le problème survient lorsque des pirates commencent à injecter du code dans le processus au lieu de simplement saisir leurs coordonnées. Cela ressemble à une attaque par injection SQL, mais appliquée à l'application de messagerie. Un exemple de requête manipulée qui enverrait du spam depuis votre application vers un utilisateur ciblé pourrait ressembler à ceci :

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed message

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

Selon les compétences de l'utilisateur malveillant et ses intentions, les attaques par injection d'en-tête d'e-mail peuvent aller de la simple nuisance à une dangerosité élevée. Au niveau le plus bas, ils pourraient insérer leurs coordonnées dans le champ CCI d'un message sortant envoyé à une boîte aux lettres secrète ou non divulguée au sein de votre entreprise, la révélant ainsi à un pirate.

Plus préoccupant encore, cela pourrait leur permettre de prendre le contrôle total de votre serveur de messagerie pour envoyer du spam, du phishing ou d'autres e-mails malveillants depuis votre organisation. Ils n'auraient pas besoin de falsifier l'origine de l'e-mail, car il proviendrait réellement de vos serveurs internes. Et si vous ne surveillez pas cette activité, ils peuvent même automatiser le processus, envoyant des centaines ou des milliers d'e-mails via vos serveurs, donnant l'impression que c'est votre organisation qui est à l'origine de cette activité.

Éliminer le problème de l'injection d'en-tête d'e-mail

Comme pour l'injection SQL et d'autres attaques de ce type, 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 faire confiance aux entrées utilisateur. Si un utilisateur peut saisir des informations, même dans un processus trivial comme la saisie d'une adresse e-mail, vous devez supposer le pire. Ou du moins, supposer 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 fonctionnalité de contact par e-mail à une application ou un site web. La liste blanche peut être utilisée pour autoriser 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 permettant de restreindre les fonctions au strict nécessaire. Cela empêchera tout code ou commande saisi par des utilisateurs malveillants d'être reconnu et traité par vos serveurs.

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

Pour aller plus loin, consultez les recommandations de l'OWASP sur les injections d'en-têtes d'e-mail. Vous pouvez également mettre vos nouvelles compétences défensives à l'épreuve avec la démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir des experts en la matière. Pour en savoir plus sur la neutralisation de cette vulnérabilité et d'une multitude d'autres menaces, visitez le blog de Secure Code Warrior.

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