Sunday 14 March 2010
Article  Cloud security assessment scheme launched

Sunday 14 March 2010
In Brief  Human element undermines encryption

Thursday 11 March 2010
Article  Digital privacy framework steps closer?

Monday 8 March 2010
Audio Podcast  Web 2.0 and Social Networks in the Enterprise

Sunday 7 March 2010
Article  Digital Economy Bill raises privacy concerns

Wednesday 3 March 2010
Article  Cloud security threats identified by CSA

Tuesday 2 March 2010
In Brief  Vote for your CSO Interchange topics

Thursday 25 February 2010
Article  Cloud Computing : a simple question of supplier risk

Monday 22 February 2010
Article  Most dangerous coding errors outed

Monday 22 February 2010
In Brief  Microsoft IE users to get browser choice update

Friday 19 February 2010
Article  Google Buzz fail highlights privacy expectation rise

Thursday 18 February 2010
In Brief  Annual hacking challenge aims for mobiles and browsers

Wednesday 17 February 2010
Audio Podcast  The Challenges of Cross Border eID

Monday 15 February 2010
Audio Podcast  The Readiness of eID in Europe Part 2

Sunday 14 February 2010
Audio Podcast  The Readiness of eID in Europe Part 1

Written by Jerome Saiz (SecurityVibes)
Published on Wednesday 15 February 2006
0 comment(s) | Subnetwork France

Une vague de détournement de sites web frappe actuellement les serveurs dédiés. Les sites se retrouvent contraints à envoyer des quantités massives de spam, nuit et jour, jusqu'à devenir quasi-inutilisables pour toute autre tâche.Certes, la chose n'est pas nouvelle : depuis longtemps déjà les spammeurs détournent allègrement les scripts d'envoi d'emails mal sécurisés, tels ceux qui permettent de stipuler directement l'adresse du destinataire. Ils s'en prennent même à certains scripts très populaires, tel le tristement célèbre FormMail.pl.Mais l'originalité de la vague de détournement actuelle, c'est que les victimes sont des sites dont les webmasters ont pourtant pris soin de protéger leur script d'envoi de courriers.L'attaque frappe ainsi des responsables de site a peu près compétents et capables de programmer en PHP. Lorsque ceux-ci développent un formulaire chargé d'envoyer du courrier depuis leur site (une page de contact par exemple), ils prennent souvent la peine de limiter les destinataires à quelques adresses prédéfinies inscrites "en dur" dans le code PHP. En spécifiant ainsi les seuls destinataires possibles, ils pensent empêcher l'utilisation du script pour relayer des courriers à n'importe qui. Mais ils se trompent !Ajout d'en-têtes à volontéA l'aide de robots, les spammeurs explorent les sites à la recherche d'un formulaire de contact à abuser. Peu importe qu'il ne propose pas de saisir directement l'adresse du destinataire. Ce qui les intéresse, c'est surtout qu'il permette à l'internaute de saisir son adresse email en tant qu'expéditeur.Une fois un tel formulaire repéré, le spammeur procède à une tentative de détournement : il utilise le formulaire pour envoyer un courrier tout simple. Mais après avoir inscrit une adresse quelconque dans le champs "Expéditeur", il ajoute un caractère de nouvelle ligne (" " ou " ") suivi, par exemple, de la mention BCC:, puis d'une adresse email de test.Lorsque le contenu de ce champs sera inséré dans les headers de l'email construit par le script, le saut de ligne provoquera la création d'une nouvelle ligne d'en-tête, qui sera celle que le spammeur a spécifié dans le champs "Expéditeur" du formulaire. On appelle ça une attaque par injection d'en-têtes, et ça marche très bien ! Si le spammeur reçoit le courrier à l'adresse qu'il a injecté, c'est que le formulaire peut être utilisé de manière industrielle. Des outils lui permettront alors d'automatiser la tâche : il exécutera le script vulnérable directement (sans passer par le formulaire) et en insérant ses propres en-têtes BCC: garnis de centaines d'adresses emails à spammer. Et cela nuit et jour.Mais cette attaque n'est pas utilisable qu'avec les seuls scripts de contact. Elle permet également de détourner les fonctions d'envoi d'un article à un ami que l'on retrouve souvent sur les sites d'actualité. Ces derniers n'autorisent certes pas de soumettre du contenu (puisqu'ils n'envoient que l'article demandé), mais ils permettent de spécifier l'adresse de l'expéditeur. Il suffit alors au spammeur, après avoir injecté son champs BCC: pour définir ses propres destinataires, de créer une nouvelle ligne afin de spécifier que le courrier est en HTML (Content-Type:text/html). Il pourra ensuite y placer son contenu, qui apparaîtra avant l'article légitime.Se protéger efficacementLa solution pour se protéger contre une telle attaque est d'interdire les sauts et retours de ligne dans les adresse emails fournies par l'utilisateur. Cela peut se faire en modifiant le code de la fonction mail() dans les sources de PHP ou, plus simplement, en filtrant correctement les entrées de l'utilisateur (ce qui devrait déjà être une habitude !).Ainsi une adresse email ne doit pas être composée d'autre chose que de deux chaînes de caractères usuels (des lettres, des chiffres, le point, le tiret et l'underscore), séparées par un caractère @ et suivies d'un point puis enfin d'une nouvelle série de lettres (et uniquement des lettres). Une telle règle peut facilement être décrite à l'aide d'une expression régulière.Il suffit alors de créer une fonction "de sécurité" qui sera appellée pour contrôler chaque adresse avant de la passer au script proprement dit.Bien sûr, si vous ne comprenez pas un traître mot de la phrase précédente (ou de cet article !), c'est que vous ne devriez pas développer vous-même des scripts PHP destinés à des environnements de production !

• Un article plus technique sur l'injection d'en-têtes (en français). L'article date de plus de deux ans... les bonnes habitudes sont longues à prendre !