Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brandin-Bernard et aujourd'hui on va parler des SVG et plus particulièrement des failles
de sécurité qui peuvent apporter.
Alors vous connaissez forcément le SVG, c'est un format d'image vectorielle qui est
destiné tout simplement à ficher des images mais qui ne seront jamais pixelisés parce
qu'elles sont dessinées grâce à du code.
Alors souvent elles sont générées ou créées sur des logiciels comme Adobe Illustrator,
Figma et j'en passe.
Et ce format il est maintenant très très courant, il est supporté partout, presque
partout parce que non, certaines applications mobiles, certains systèmes mobiles, il n'est
pas très bien supporté.
Et pourtant il peut représenter une faille de sécurité importante, notamment sur le
web.
Alors qu'est ce que c'est que cette faille ? Le problème du SVG c'est que dans l'inconscient
collectif il est considéré on va dire comme une simple image et pourtant c'est peut-être
une image mais ce n'est pas un tableau du pixel.
Il faut toujours garder en tête qu'un fichier SVG, il contient rien d'autre que du code
XML.
Et le langage compatible avec l'XML qui est interprété par votre navigateur, c'est
le HTML.
Et donc pour petit rappel, quand on peut écrire du HTML, on peut aussi écrire du JavaScript
dans une balise script.
Et voilà comment avec un simple fichier SVG, en réalité on a tout ce qu'il nous faut pour
créer une faille XSS.
XSS c'est pour cross-site scripting et c'est donc exécuter du code non désiré dans
une page qui appartient à quelqu'un.
Alors l'une des particularités du SVG c'est que son type MIM, il correspond à celui
d'une image classique et donc image slash SVG plus XML.
Alors le type MIM c'est un standard qui permet d'indiquer la nature et le format
d'un document.
C'est ce qu'utilise le navigateur pour savoir comment afficher une ressource et non pas
justement avec simplement l'extension du fichier.
Alors imaginons un site web qui permettrait à ses utilisateurs d'uploader une image
en tant que photoprofil, ce qui est plutôt courant.
Si le serveur se cantonne simplement à vérifier si le type MIM du document envoyé correspond
à image slash étoile, alors il laissera passer le fichier SVG sans problème.
Voilà comment on peut se retrouver déjà avec un morceau de code non voulu sur son
serveur et ce serveur il sera en mesure de le fournir aux clients tout simplement parce
que pour lui il n'y a rien d'anormal.
Alors heureusement les attributs SRC et background image, ils exécutent pas le code injecté
dans un SVG.
Mais déjà si jamais le site décide de l'injecter réellement en tant que code SVG et pas potentiellement
il pourrait être exécuté, mais surtout il reste une solution pour qu'un utilisateur
exécute le code caché dans l'image.
Il suffit d'insérer le lien de sa photo de profil ailleurs sur le site et si un utilisateur
clique dessus l'image s'ouvrira directement dans le navigateur.
Et qu'est ce qui se passe à ce moment là ?
Eh bien quand une image SVG elle est ouverte directement dans le navigateur, tout le code
contenu à l'intérieur est exécuté.
Alors si ça vous intéresse je vous ai donné un exemple dans l'article qui est à l'origine
de cet épisode du podcast et donc en cliquant dans le lien de l'article vous pouvez trouver
un exemple avec une image SVG qui contient une fausse faille XSS évidemment et que j'ai
injecté sur mon site.
Alors en réalité c'est quoi le danger si le code il exécutait sur une autre page ?
Eh bien le problème il se cache dans le fait que le code frauduleux s'exécute dans une
autre page d'accord mais vous êtes quand même sous le même nom de domaine.
Et qu'est ce qui est accessible uniquement depuis le domaine du site ?
Eh bien les cookies et le local storage.
Donc si jamais j'ai un utilisateur qui est connecté et que je clone son token de connexion
pour l'envoyer à mon serveur grâce au bout de code que j'ai inséré dans l'image,
eh bien je pourrais me connecter sur le site à la place de l'utilisateur.
Alors comment est-ce qu'on fait pour se prémunir pour éviter ce genre d'attaque là ?
Evidemment le meilleur moyen c'est d'empêcher les utilisateurs de mettre en ligne des fichiers SVG
sur votre plateforme tout simplement mais aussi de ne pas ajouter soi-même des images SVG
qui viendraient de sources non fiables.
Evidemment si jamais c'est une fonctionnalité indispensable sur votre site que les utilisateurs
puissent ajouter des SVG eh bien il faudra bien nettoyer le code du fichier SVG pour enlever
tout le code HTML et JavaScript avant de l'enregistrer sur le serveur.
Si jamais vous pensez que c'est un problème qui n'arrive quasiment jamais tout simplement
parce qu'on n'écrit personne et qu'il y a un JavaScript dans du SVG, et bien sachez que si jamais
vous tombez sur des sites qui proposent des SVG animés, eh bien l'animation se fait grâce à un code
JavaScript contenu dans le SVG qui va simplement déplacer les morceaux du SVG.
Donc c'est en réalité une technique très commune dans l'animation de SVG et donc on peut
détourner pour faire un SVG frauduleux.