Des recherches récentes alertent sur un angle mort classique de la sécurité des e-mails : les attaques CSS webmail. L’idée n’est pas seulement d’usurper un message, mais d’exploiter les règles de rendu que l’interface webmail applique au contenu HTML. Dans plusieurs scénarios, le contenu supposé « non fiable » peut franchir sa frontière et interférer avec les contrôles de la page d’authentification ou de l’interface de rédaction.
Lors de Black Hat USA 2026, le chercheur PortSwigger Gareth Heyes a présenté des chaînes d’attaque reposant sur HTML et CSS autorisés par les clients webmail. Les démonstrations couvrent notamment Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail et AOL Mail, avec des impacts allant de la capture de mots de passe à la fuite de jetons, et même au détournement d’outils d’IA connectés.
Pourquoi le CSS dans un e-mail peut devenir dangereux
Le point clé des recherches est simple : certains webmails autorisent une partie du contenu HTML dans les messages. Tant que ce contenu reste « isolé », le risque diminue. Mais les attaques CSS webmail s’attaquent précisément à la manière dont l’application et le navigateur finissent par créer ou modifier le DOM (l’arbre de la page) à partir de ce contenu.
Deux voies reviennent dans les travaux :
- Exploiter ce que le webmail accepte déjà dans les e-mails (notamment des éléments HTML et des propriétés CSS).
- Créer un décalage entre ce que le filtre/sanitizer considère acceptable, et ce que le navigateur ou l’application produit réellement après traitement.
Dans les deux cas, le contenu non fiable peut « traverser » la frontière entre l’e-mail et l’interface web de confiance : formulaires, actions d’interface, requêtes réseau, ou logique de manipulation interne.
Des chaînes d’attaque concrètes : mots de passe, jetons et prises de compte
Les présentations incluent plusieurs scénarios. À chaque fois, l’objectif consiste à obtenir des informations sensibles en profitant d’actions utilisateur et de particularités de rendu.
Outlook : une page d’identification usurpée et une capture de saisie
Dans une chaîne combinant Outlook et Firefox, l’attaque met en place un écran de connexion Microsoft contrefait. L’idée est de capter le mot de passe que la victime saisit. Le papier ne précise pas clairement si la chaîne complète a été corrigée, mais il mentionne que certains éléments étaient déjà en discussion côté protections.
Yahoo Mail et AOL Mail : exposition d’un jeton de connexion Medium
Un autre scénario, basé sur Yahoo Mail et AOL Mail, s’appuie sur une sorte de « course » lors du collage de contenu. Le démonstrateur (notamment autour de Medium) vise à exposer un jeton de connexion d’environ 12 caractères. Une fois reconstruit, ce jeton permettrait à l’attaquant de se connecter comme la victime.
Gmail : fuite d’un jeton Slack après injection de prompt et interaction
Les travaux décrivent également une chaîne Gmail combinant injection de prompt et interaction utilisateur. Le but affiché est d’exfiltrer un jeton Slack à l’issue d’un flux impliquant des actions validées par l’utilisateur.
Proton Mail : un vecteur visant l’adresse IP
En complément, le chercheur présente un vecteur Proton Mail qui pourrait révéler l’adresse IP du destinataire. La documentation actuelle de Proton indique que le service est conçu pour masquer l’adresse IP personnelle et le moment exact de l’ouverture d’un e-mail ; l’attaque discutée s’inscrit donc dans l’examen d’autres chemins possibles.
Quand la sécurité du navigateur et celle du sanitizer ne parlent pas la même langue
Les attaques CSS webmail exploitent souvent des différences de comportement entre la phase de filtrage (sanitizer) et la phase de rendu (navigateur/application). Autrement dit : même si l’e-mail passe un contrôle, le système peut encore créer des structures DOM supplémentaires ou déclencher des règles CSS qui n’étaient pas prévues.
Un exemple marquant dans Outlook illustre la mécanique :
- Des éléments de libellés autorisés peuvent déclencher des contrôles en dehors du message.
- Un script applicatif peut convertir des attributs personnalisés (sanitisés) en nœuds DOM supplémentaires, avec du CSS qui échappe à la liste d’autorisation.
- Une astuce de parsing via media queries permet ensuite d’introduire du CSS arbitraire.
Dans les détails de la démonstration, la chaîne masque en apparence un contrôle de sélection, et s’appuie sur un comportement de synchronisation spécifique côté Firefox pour rendre la capture exploitable en temps réel.
Exfiltration par clic : contourner le blocage des ressources externes
Quand la politique Content Security Policy (CSP) bloque l’appel à des ressources externes, une autre méthode peut apparaître : l’exfiltration déclenchée par clic.
Le principe repose sur une injection CSS associée à un jeton rendu en clair dans l’e-mail. Les règles CSS peuvent alors déterminer quels chiffres apparaissent, leur fréquence, puis :
- masquer les liens qui ne correspondent pas ;
- garder le lien pertinent visible sur la page ;
- faire envoyer par un clic les informations nécessaires à l’attaquant.
Les travaux montrent la faisabilité conceptuelle : la victime clique, et le navigateur transmet implicitement des indices au serveur de l’attaquant.
Le tournant IA : prompts indirects et fuites via outils connectés
Au-delà de l’authentification classique, les recherches pointent un risque plus récent : l’e-mail connecté à des outils d’IA. Les auteurs décrivent comment une chaîne de rendu webmail peut pousser un assistant à traiter des consignes cachées.
Dans le scénario Gmail, le travail mentionne une option liée à image-set() pouvant déclencher une requête externe malgré le filtrage. L’attaque a ensuite été chaînée à un e-mail d’injection de prompt traité par Anthropic Claude Cowork via un connecteur Gmail.
En pratique (selon la configuration de démonstration), l’attaquant déclenche un e-mail de confirmation de jeton Slack. Une fois que la victime demande à Cowork de traiter les e-mails, les instructions injectées amènent l’outil à extraire le jeton et à le placer dans un brouillon HTML. Le fait de consulter ce brouillon contribue à la fuite.
Fastmail : manipulation de texte visible vs instructions lues par l’IA
Le papier décrit aussi un ciblage Fastmail visant un navigateur associé à OpenAI Atlas AI. L’idée : grâce à des pseudo-éléments CSS et à la gestion de l’opacité, l’humain voit un texte inoffensif tandis que le modèle lit des éléments cachés. Lorsqu’un utilisateur demande à l’IA de traduire le texte visible, les consignes cachées déclenchent des actions supplémentaires, comme l’ouverture de nouveaux onglets et l’encodage d’informations dans des fragments d’URL.
Le document précise qu’OpenAI prévoit de déprécier Atlas et que l’arrêt de fonctionnement est annoncé au 9 août 2026.
Recommandations de défense : isoler, restreindre, vérifier
Les chercheurs mettent surtout l’accent sur la mitigation. Leur approche commence par une règle de base : ne pas faire confiance au contenu HTML d’un message, même s’il a été « nettoyé ».
Parmi les recommandations centrales :
- Isoler strictement les e-mails HTML dans des ifram es sandboxés.
- Limiter finement le CSS autorisé, via des listes de caractères et de validation.
- Contrôler les « gadgets » CSS avant d’autoriser des attributs personnalisés.
- Bloquer certains menus et des sélecteurs CSS jugés dangereux.
- Empêcher les requêtes d’images contrôlées par l’attaquant et surveiller les domaines explicitement autorisés.
Statut des preuves et correctifs évoqués
Le papier présenté est accompagné de preuves de concept. Toutefois, il est important de noter que l’étude ne rapporte pas d’exploitation malveillante en production. Des PoC publics restent disponibles à la date du 8 août.
Les auteurs indiquent aussi des informations de suivi :
- Fastmail aurait corrigé deux bugs liés à des mutations CSS.
- Pour Proton Mail, une dérivation passant par un proxy aurait cessé de fonctionner lors d’une nouvelle retestation.
- En revanche, certains éléments étaient encore fonctionnels au moment de la publication (par exemple des points liés à Outlook et à une technique d’évitement associée à Gmail, datée du 6 août).
Enfin, le document ne tranche pas explicitement la question de savoir si la chaîne complète de capture de mot de passe côté Outlook était intégralement corrigée.
Ce que ces résultats changent pour votre sécurité e-mail
Les attaques CSS webmail rappellent que la sécurité des messageries web doit aller au-delà du filtrage « à l’œil ». Si le rendu produit un comportement inattendu (DOM, requêtes réseau, actions d’interface), l’attaque peut contourner les protections.
Pour les équipes qui gèrent des webmails, la priorité est claire : isolation et restrictions strictes, puis validation continue des comportements côté navigateur. Pour les utilisateurs, la prudence reste essentielle : ne pas copier/coller de contenu douteux dans les brouillons, éviter les actions déclenchées par des éléments trompeurs, et rester attentif aux demandes d’authentification inhabituelles.
Conclusion
Les nouvelles recherches présentées à Black Hat USA 2026 montrent que les attaques CSS webmail peuvent briser la séparation entre un message non fiable et une interface web de confiance. Elles peuvent permettre la collecte de mots de passe, la fuite de jetons, des détournements d’actions, et même des effets sur des workflows d’IA connectés.
La réponse la plus efficace combine isolation sandboxée, validation stricte du CSS, et contrôle des transformations côté application. C’est un message fort : même « propre » à première vue, un e-mail reste une surface d’attaque qu’il faut contenir.
Source: https://thehackernews.com/2026/08/new-css-attacks-can-break-webmail.html
