Se protéger du Javascript caché dans les fichiers SVG

Depuis quelque temps déjà, les développeurs de Joomla!, en plus de résoudre des failles de sécurité dans le CMS lui-même, font des recommandations de "durcissements" pour améliorer la sécurité des sites. Cela a commencé avec la version 3.9.3 qui incluait, dans le fichier htaccess.txt, une instruction pour désactiver la fonctionnalité de détection de type MIME dans les navigateurs Web, ce qu'on appelle le "sniffing". Avec la version 3.9.21 qui sort aujourd'hui, ils vont un peu plus loin avec la protection des fichiers SVG par une Content Security Policy (CSP). Voyons cela un peu plus en détail.

Protection avec l'en tête X-Content-Type-Options

Revenons d'abord rapidement sur le premier "durcissement" proposé : les type MIME sont des instructions données  par le site au navigateur pour lui indiquer comment interpréter les différents types de fichiers qui lui sont proposés (images, CSS, Javascript,...).  Comme il existe la possibilité, dans le navigateur, de modifier à la volée ces types MIME, cela peut poser un problème de sécurité. En tout cas, c'est ce qu'on peut lire un peu partout !

Comme il s'agit d'une implémentation simple à réaliser et que, depuis la mi-2018, c'est également une recommandation de Google, il vaut mieux s'y conformer. Vous trouverez les instructions pour la mettre en place en consultant les messages de post-installation dans votre administration Joomla!. Il s'agit de quelques lignes à ajouter à votre fichier .htaccess (ou web.config si vous utilisez un serveur Windows).

Notez que pour les clients dont nous assurons l'hébergement, nous appliquons cette directive directement au niveau du serveur, donc ils n'ont pas à se soucier de faire la modification proposée dans le .htaccess.

Protection contre le Javascript dans les fichiers SVG

Voyons  maintenant le nouveau durcissement proposé. Tout d'abord, pour ceux qui ne le sauraient pas, le SVG (Scalable Vector Graphics, en français « graphique vectoriel adaptable ») est un format de données conçu pour décrire des ensembles de graphiques vectoriels. Dans un site, il est utilisé pour afficher les logos et les icônes avec le très gros avantage de conserver un rendu parfait quelle que soit sa taille d'affichage, sans modification du poids du fichier. Il remplace donc avantageusement le format PNG ou GIF en offrant des fichiers beaucoup plus rapides à charger pour un rendu graphique équivalent. A l'heure où chaque milliseconde gagnée dans le chargement d'une page Web compte, c'est devenu un format incontournable.

Voici 2 exemples, simples, des différences :

Exemple icône au format SVG

Exemple icône au format PNG

Visuellement, elles sont identiques mais le fichier de la seconde "pèse" 15 Ko tandis que celui de la première n'en fait que 7, soit moins de la moitié. Et si on voulait afficher de plus grandes dimensions, le fichier de l'image PNG continuerait à augmenter tandis que le poids de celui de l'image SVG resterait figé à 7 Ko.

Mais les fichiers SVG étant en réalité des sortes de fichiers "textes", c'est-à-dire constitués d'instructions codées, ils peuvent contenir aussi du code CSS (pour des changements d'apparence en fonction de la taille de l'écran sur lesquels ils s'affichent) et du Javascript. Celui-ci sert à rendre le fichier interactif, comme par exemple dans le cas de représentations graphiques de données, comme des cartes dans lesquelles il est possible de zoomer ou de se déplacer ou pour créer des animations (voir un exemple dans les ressources à la fin de l'article).

Mais comme souvent, certaines personnes mal intentionnées utilisent des fonctions utiles à des fins malhonnêtes et le Javascript inclus dans le fichier SVG peut aussi servir à voler des cookies de sessions (et donc à usurper l'identité d'un visiteur connecté) ou des données introduites dans un formulaire. Il est donc important d'empêcher que des données soient envoyées vers des sites non autorisés et surtout que ceux-ci n'injectent quoi que ce soit dans vos pages. L'exemple le plus célèbre de piratage via des fichiers SVG est l'infection par le virus Locky via la messagerie Messenger de Facebook en 2016.

Utilisez une Content Security Policy (CSP) pour protéger son site

Une CSP est un ensemble d'instructions envoyées au navigateur pour indiquer quels sont les sites autorisés à envoyer du contenu sur vos pages. Quand on parle de contenu, il s'agit de scripts, de feuilles de style (CSS), de media (images, vidéo, ...), de polices, de frames, d'actions de formulaire et de plugins.

Comme pour la protection évoquée au début de l'article, il s'agit d'une en-tête placée dans le fichier .htaccess. Ici en effet, à moins d'avoir un seul site sur le serveur, il est difficile d'intégrer ces directives au niveau du serveur lui-même s'il héberge plusieurs sites parce qu'on est dans le "sur-mesure" ! Avec une CSP complète, vous devez faire une liste exhaustive de tous les sites autorisés à vous envoyer du contenu. S'il y a des oublis, vous aurez des erreurs d'affichage (images manquantes, mise en page incorrecte) ou des dysfonctionnements (scripts bloqués).

Pour vous aider à rédiger une CSP, il existe des outils en ligne et pour repérer les erreurs, la Console disponible dans les navigateurs, accessible par exemple sur Firefox en allant dans Outils > Développement Web > Console Web, vous indiquera quelles sont les ressources bloquées par votre CSP, vous permettant ainsi de la corriger. N'oubliez pas de la mettre à jour chaque fois que vous ajoutez un nouveau service comme Google Analytics, des vidéos YouTube, un service de chat externe, ...

C'est une protection très efficace et devenue quasi indispensable pour tout site sérieux de sa sécurité mais dont la mise en place peut être déroutante pour l'utilisateur moyen. Nous proposons ce service à un prix forfaitaire de 50 € (hors TVA), n'hésitez pas à nous contacter à ce sujet.

En ce qui concerne la modification proposée par Joomla! par contre, pas de difficulté : il vous suffit d'insérer le code proposé dans votre fichier .htaccess. Pour les clients hébergés par Better Web ou ceux ayant souscrits à notre formule de maintenance, nous effectuons cette opération lors de la mise à jour du noyau du CMS.