Nouvelle attaque de clickjacking SVG moderne trompant les utilisateurs et contournant les alertes

• Une nouvelle technique de clickjacking basée sur les filtres SVG a été proposée, étendant les attaques classiques de clic forcé en attaques interactives plus complexes
• Les éléments de filtre SVG tels que feColorMatrix, feDisplacementMap et autres peuvent être appliqués à des iframes cross-origin, ce qui rend possibles des manipulations visuelles et l’exfiltration de données
• En combinant ces filtres, des opérations de lecture de pixels, de logique et de manipulation d’interface conditionnelle deviennent possibles, permettant des scénarios de clickjacking multi-étapes ou d’incitation de saisie
• Un cas réel a prouvé l’attaque via une vulnérabilité de Google Docs, pour laquelle le chercheur a reçu une récompense de 3133,70 $ du programme Google VRP
• Cette technique met au jour une nouvelle surface d’attaque dans le modèle de sécurité des navigateurs et montre comment l’usage logique des filtres SVG peut devenir une menace

---

Vue d'ensemble du clickjacking SVG

• Le clickjacking traditionnel consiste à superposer une iframe pour pousser un utilisateur à cliquer sans le vouloir
• Le clickjacking SVG récemment proposé exploite des filtres SVG pour permettre des interactions et des fuites de données plus complexes
• Des filtres comme feColorMatrix et feDisplacementMap s’appliquent aussi aux documents cross-origin, permettant de manipuler visuellement du contenu externe

Composition des filtres SVG

• Les principaux éléments de filtre sont <feImage>, <feFlood>, <feOffset>, <feDisplacementMap>, <feGaussianBlur>, <feTile>, <feMorphology>, <feBlend>, <feComposite>, **<feColorMatrix>
• Ils combinent et transforment des images d’entrée pour produire de nouvelles images, et peuvent être chaînés entre eux
• Cette combinaison offre une grande liberté pour implémenter des effets visuels, masquages et manipulations de couleurs

Exemples d'attaque

• Fausse captcha : utilisation de feDisplacementMap pour déformer du texte et amener l’utilisateur à entrer un code sensible
• Masquage de texte gris (grey text hiding) : suppression d’indices et de messages d’erreur dans les champs via feComposite et feMorphology, afin d’inciter l’utilisateur à saisir le mot de passe choisi par l’attaquant
• Lecture de pixels : détection de la couleur de pixels précis pour contrôler le comportement des filtres, permettant des attaques réactives détectant clics, survols et état des saisies

Logique booléenne et attaques composées

• En combinant feBlend et feComposite, il est possible d’implémenter des portes logiques telles que AND, OR, XOR, NOT
• Cela permet de construire une circuiterie logique complète directement dans le filtre SVG et d’automatiser des scénarios de clickjacking en plusieurs étapes
• Dans l’exemple d’attaque de l’application Securify, l’ouverture de boîtes de dialogue, les clics sur cases à cocher et les clics sur boutons sont contrôlés de façon logique pour tromper l’utilisateur

Cas réel : vulnérabilité Google Docs

• Détection et manipulation via la logique de filtre SVG des popups et champs de saisie apparus après un clic sur le bouton « Generate Document » de Google Docs
• L’état de focus des champs, les textes gris et les écrans de chargement sont détectés en temps réel pour piloter le déroulement de l’attaque
• Cette attaque a été signalée à Google et a donné lieu à une prime de bug bounty de 3133,70 $

Application aux QR codes

• Une logique de génération de QR code peut être implémentée dans un filtre SVG, en encodant des données de pixels puis en les affichant sous forme de code QR
• Quand l’utilisateur scanne le QR code, les données sont envoyées au serveur contrôlé par l’attaquant
• L’usage de feDisplacementMap et de la correction d’erreur Reed–Solomon permet de générer des QR codes lisibles

Potentiel d’usages supplémentaires

• Des usages variés sont possibles, comme la lecture de texte, l’exfiltration de données basée sur les clics, l’insertion de faux curseurs de souris
• Les attaques peuvent être mises en place sans JavaScript, avec seulement CSS/SVG, ce qui laisse entrevoir des possibilités de contournement du CSP

Intérêt de la recherche

• Le clickjacking logique basé sur les filtres SVG est une nouvelle technique non couverte par les travaux antérieurs
• Les travaux précédents présentaient SVG comme un simple outil de dissimulation visuelle ; cette recherche démontre au contraire l’exécution logique et le contrôle d’interactions
• L’auteur la présente comme une nouvelle classe de vulnérabilité, insistant sur la nécessité de revoir les mécanismes de sécurité des navigateurs

Conclusion

• Cette recherche est saluée comme le premier cas d’attaque de sécurité exploitant des filtres SVG comme un langage de programmation
• L’auteur prévoit d’en parler à la fin de 2025 lors de 39c3 et Disobey 2026
• Le billet a été rédigé avec 42 Ko de HTML/CSS/SVG uniquement, sans images ni JS, montrant la créativité possible en recherche de sécurité expérimentale

[GN⁺]

Commentaire Hacker News

• Si les développeurs configurent correctement l’en-tête X-Frame-Options, ce problème est résolu
  Mais dans la pratique, j’ai l’impression qu’on réagira plutôt en supprimant la moitié de la spec SVG dans les navigateurs au nom de la sécurité

  • Ce n’est pas totalement réglé. Certaines applications, comme Google Docs, ont besoin d’être intégrées dans des frames
    Et ce type d’attaque reste possible sur des sites où l’on peut faire de l’injection HTML sans passer par une frame
  • SVG est truffé de mines antipersonnel de sécurité. Surtout quand il s’agit de SVG fournis par les utilisateurs, donc non fiables, le plus simple est encore de les désactiver complètement

• J’ai déjà désactivé SVG pour des raisons de sécurité
  Mais ces jours-ci, je me demande s’il ne faudrait pas aussi désactiver le CSS
  J’aurais aimé que le CSS reste un outil servant simplement à mettre en forme du texte, mais il s’est transformé en sorte de langage de programmation facile à détourner par les hackers ou les annonceurs

  • Je comprends très bien le « j’aurais aimé qu’on laisse le CSS simple », mais en réalité ce genre d’attaque était bien plus facile à réaliser à la fin des années 2000
    Aujourd’hui, c’est presque impossible
  • Plutôt que de casser le navigateur pour renforcer la sécurité, je pense qu’il vaut mieux garder les données sensibles hors du navigateur
  • Le vrai cœur du problème, ce n’est pas le CSS mais les iFrame. C’est une source continue de failles de sécurité depuis les débuts du navigateur
  • Je me demande s’il y a d’autres raisons de sécurité que cette démo. Sur la plupart des plateformes, cette attaque ne fonctionne pas
  • C’est une réaction excessive. La probabilité de se faire avoir par ce type d’attaque est très faible, et elle ne permet pas non plus de contourner le sandboxing ni les cookies de session

• En voyant « l’exemple qui détecte si un pixel est d’un noir pur pour activer ou désactiver un filtre », j’étais complètement perdu
  Je ne comprends pas pourquoi HTML/CSS est devenu aussi complexe
  Il y a un <checkbox> caché et un <label> ; quand on clique, la case se coche ou se décoche, puis le style change selon l’état uniquement via le CSS
  Le SVG ne dessine en fait rien du tout et ne fait que définir des filtres
  Le fait qu’il y ait deux <feTile> pour séparer la zone de mosaïque et la zone de sortie est aussi étrange
  Et c’est quoi encore ces éléments comme <fake-frame> ou <art-frame> ?

  • Moi, je trouve cette structure plutôt élégante. On peut créer du contenu interactif sans JavaScript
    Le fait qu’un clic sur <label> bascule l’état de la case à cocher est un comportement natif du HTML
    L’état est détecté avec le sélecteur CSS :has()
<feTile> est un unique élément de filtre, utilisé pour mettre l’image d’entrée en mosaïque ou la rogner
    <fake-frame> et <art-frame> sont des éléments personnalisés définis par l’auteur
    Le sujet est résumé dans ce billet de blog
  • En réalité, la plupart de ces fonctions ne sont pas tant « modernes » que des choses qui existent depuis les années 1990
    Le clic sur <label> qui déplace le focus reprend une tradition des interfaces desktop
    La possibilité de changer le style selon l’état d’une case à cocher existe depuis l’époque de Firefox 1
    L’intégration directe de filtres SVG dans du HTML est elle aussi une vieille fonctionnalité
    Autrement dit, le problème n’est pas un nouvel HTML, mais une combinaison de vieilles fonctionnalités

• Cette démo m’a rappelé les anciens hacks de Flash Player
  C’est similaire à la façon dont on trompait les utilisateurs pour qu’ils autorisent l’accès au stockage système
  Les graphismes vectoriels donnent vraiment l’impression d’être incapables de se contrôler eux-mêmes

• Le SVG adder ressemble à une œuvre d’art. Vraiment superbe

  • C’était une démo extrêmement puissante. Je l’ai appris aujourd’hui : pour la complétude de Turing, la seule complétude fonctionnelle ne suffit pas ; il faut aussi du stockage et un accès arbitraire
    J’ai pris comme référence ce post Stack Overflow

• Sur mon Chrome Android, enfin plus précisément le navigateur Kiwi, l’affichage semble cassé ou bizarre, peut-être à cause du mode sombre
  Je me demande si d’autres voient la même chose

  • Sur Firefox, il a fallu désactiver Dark Reader pour que l’exemple s’affiche correctement
  • L’exemple lié au QR se casse lorsque le niveau de zoom n’est pas à 100 %

• Cet article m’a rappelé cette ancienne démo de calcul en CSS

• Travail vraiment impressionnant. Je ne sais pas comment corriger ça, mais il faut un correctif rapidement

• C’était un post vraiment excellent. J’ai pris beaucoup de plaisir à le lire