XSS, SQL Injection, XMLrpc - lorsqu'une mise à jour de sécurité WordPress est publiée, les rapports de mise à jour contiennent surtout des abréviations cryptiques. Même s'il est clair que ces mises à jour sont nécessaires et que le plus de sécurité est très appréciable, il est important de comprendre ce qui se cache derrière ces failles de sécurité. Car ce n'est que si tu comprends quelles sont les failles que les mises à jour comblent que tu peux prendre une décision éclairée. C'est pourquoi nous nous consacrons aujourd'hui au Cross Site Scripting, ou XSS, qui est de loin l'attaque complexe la plus fréquente sur les sites WordPress.

Les attaques de pirates informatiques peuvent être comparées à un cambriolage. Les attaques par force brute ressemblent plus à la méthode du pied de biche. Les criminels s'acharnent sur l'outil jusqu'à ce que la porte ou la fenêtre s'ouvre. Les attaques contre les vulnérabilités XSS sont par contre très sophistiquées : Les criminels savent exactement où ils doivent intervenir et accèdent de manière ciblée à un site Web.

Le Cross Site Scripting consiste à exploiter les failles de sécurité des sites Web. Des scripts malveillants sont introduits dans un contexte de confiance (ton site Web !). Comme un passager clandestin sur un bateau, ce code malveillant utilise ton site Web comme véhicule pour poursuivre ses propres objectifs.

Dans le pire des cas, des informations confidentielles sont ainsi obtenues, ou même l'accès à l'ordinateur de l'utilisateur lésé. De telles attaques ne sont pas rares : Une bonne moitié des vulnérabilités trouvées dans les plugins par le fournisseur de sécurité Wordfence en 2015 et 2016 étaient des vulnérabilités Cross Site Scripting. Souvent, une attaque XSS constitue ensuite la "base" d'autres attaques, comme par exemple les attaques de spam, de phishing ou même de DDoS. C'est pourquoi je te montre aujourd'hui, d'une part, comment fonctionne exactement le Cross Site Scripting, quels types d'attaques existent et à quel point les attaques sont dangereuses.

Le Cross Site Scripting a un principe de base

Le Cross Site Scripting fonctionne sur le principe de base de l'exploitation d'une faille et de l'introduction de code malveillant sur ton site Web. Il y a toujours un danger lorsqu'une application Web transmet des données saisies au navigateur Web sans vérifier la présence éventuelle de code de script. Un exemple clair d'une telle application web est un chat de support.

Les scripts malveillants peuvent arriver sur le serveur via l'application Web elle-même. De là, le code malveillant atterrit tôt ou tard sur les clients concernés. Un bon exemple de ce type de vulnérabilité XSS est le bug découvert en juillet 2016 dans les métadonnées des images dans WooCommerce 2 .6.2. Tout appareil sur lequel l'image concernée était regardée de plus près (par exemple en cliquant sur l'image) risquait d'être attaqué. Ainsi, les ordinateurs sur lesquels cette image a été regardée auraient pu être infectés par un virus.

Astuce populaire du Cross Site Scripting : les formulaires manipulés

XSS peut également permettre de remplacer des formulaires inoffensifs par des formulaires manipulés. Ces formulaires collectent alors les données des victimes (sur ton site web !). Même le cryptage SSL ne peut pas te protéger contre cela. Car HTTPS signifie "seulement" que la connexion entre le serveur et le client est cryptée. Mais si le formulaire lui-même est manipulé, même une connexion cryptée ne sert à rien.

Comme pour les autres types d'attaques, l'objectif est le plus souvent de monétiser. Concrètement, cela signifie que soit les données sont volées et vendues plus tard, soit les sites Web infectés sont intégrés dans un soi-disant botnet qui est ensuite loué.

3 types de XSS

Les attaques Cross Site Scripting se divisent grossièrement en trois types :

• Cross Site Scripting réfléchi
• Cross Site Scripting persistant
• Cross Site Scripting basé sur DOM ou local

En gros, les attaques XSS se déroulent comme suit : Le code malveillant est introduit là où le client attend des données (par exemple lors d'une recherche interne au site). Dans le cadre de la réponse du serveur, le code malveillant est ensuite exécuté chez le client, c'est-à-dire dans le navigateur. Et c'est là que les dommages sont causés, par exemple le vol de données.

Cross Site Scripting réfléchi

Certaines entrées, comme les demandes de recherche, sont reflétées par le serveur. Cela signifie que, par exemple, après avoir saisi "test" dans le champ de recherche, le site web affichera "tu as cherché test". Le texte saisi fait donc partie de la réponse du serveur.

C'est justement ce qui est habilement exploité : Si un script malveillant est envoyé au serveur Web au lieu d'un terme de recherche, le site Web peut être manipulé de manière à ce qu'il l'exécute finalement. Ce type d'attaque est également appelé non persistant. Le code malveillant est donc introduit temporairement sur le site Web concerné, mais n'est pas enregistré.

En juillet 2017, une telle vulnérabilité a été trouvée dans le plugin WP Statistics (et corrigée le même jour !). Une valeur de saisie sur la page 'wps_visitors_page' a été transmise sans être vérifiée, ce qui a entraîné une vulnérabilité par XSS réfléchi. Ainsi, un site web pouvait être piraté si un admin avait auparavant cliqué sur un lien manipulé en conséquence.

Cela fonctionne ainsi: des liens avec des paramètres manipulés sont diffusés aux victimes potentielles. Sans le savoir, la victime envoie une demande "manipulée" au serveur en cliquant sur le lien, et le code malveillant est exécuté en même temps que la réponse du serveur. Comme le code n'est stocké nulle part - contrairement au XSS persistant - il doit être distribué en masse aux victimes potentielles. Cela peut se faire par exemple par le biais d'e-mails ou de réseaux sociaux.

Cross Site Scripting persistant

Dans le cas du XSS permanent, ou persistant, les scripts malveillants sont stockés sur le serveur Web et livrés chaque fois qu'un client les appelle. Les applications Web qui stockent les données des utilisateurs sur le serveur et les distribuent ensuite sans vérification ni codage (entre autres les forums) sont prédestinées à ce type de situation. Ce type de script peut être particulièrement dangereux pour les blogs et les forums très fréquentés, car le logiciel malveillant peut s'y propager rapidement en raison du grand nombre d'utilisateurs.

Exemple: Dans un forum, les messages postés sont enregistrés dans une base de données. Il n'est pas rare qu'elles soient stockées sans être vérifiées et non cryptées. Cette opportunité est souvent exploitée et permet d'ajouter un script malveillant à un message de forum normal (de manière simple à l'aide d'un commentaire). Les utilisateurs reçoivent le lien correspondant au post soit par mail, soit parviennent par hasard à l'entrée correspondante et exécutent le script en appelant le post. Maintenant, les clients concernés peuvent par exemple être "espionnés" ou ajoutés à un botnet pour d'autres attaques.

Cross Site Scripting basé sur DOM ou local

Contrairement au XSS persistant et réfléchi, le Cross Site Scripting basé sur le DOM (Document Object Model) fonctionne en exécutant des scripts côté client. Cela signifie que le serveur ne se rend pas compte d'une telle attaque et que les mesures de sécurité côté serveur n'aident pas non plus.

Un exemple connu d'une telle faille a été le cas du package genericon. Le package genericon est un ensemble d'icônes utilisé par de nombreux plugins. Un fichier HTML dans cet ensemble d'icônes a permis d'introduire le code malveillant correspondant.

La condition préalable à une attaque XSS basée sur le DOM est que les utilisateurs cliquent sur une URL manipulée. En appelant cette URL, le code malveillant peut être exécuté par une faille dans un script côté client. Le fait qu'il faille d'abord cliquer sur un lien fait du XSS basé sur le DOM un type d'attaque un peu plus difficile et donc moins probable.

Exemple: l'URL manipulée est cliquée et envoie une demande à l'application web. Celle-ci répond en transmettant le code du script (qui est erroné mais pas manipulé) au navigateur pour y lancer l'exécution du script. Les paramètres manipulés de l'URL sont alors interprétés dans le navigateur du client comme faisant partie du script et sont exécutés. Le site Web affiché dans le navigateur est ainsi modifié et les utilisateurs voient maintenant - sans s'en rendre compte - le site Web manipulé.

Mesures contre le Cross Site Scripting

Les meilleures mesures contre les attaques Cross Site Scripting sont faciles à mettre en œuvre. Appuie-toi sur des mises à jour régulières, des pare-feux et des listes blanches. En second lieu, la sortie du serveur peut également être sécurisée.

Mises à jour régulières

Les points faibles par lesquels le code malveillant est introduit se trouvent soit dans le cœur de WordPress, soit dans les plugins ou les thèmes. C'est pourquoi les mises à jour régulières de tous ces composants sont si importantes. Ces mises à jour corrigent les failles trouvées jusqu'à présent.

Il est également judicieux de lire régulièrement les détails des mises à jour afin de savoir quelles sont les failles de sécurité qui sont régulièrement comblées par les mises à jour. Pour les mises à jour de maintenance et de sécurité du WordPress Core, ces informations sont par exemple documentées sur le blog WordPress.

Pare-feux et listes blanches contre les attaques XSS simples

Une autre mesure de protection simple contre les attaques XSS sont les soi-disant pare-feu d'application web, ou WAF. Ces pare-feux sont au cœur des grands plugins de sécurité et sont alimentés par l'équipe de recherche respective du fabricant avec les dernières vulnérabilités. Un WAF est généralement une procédure qui protège les applications Web contre les attaques via le protocole de transfert hypertexte (HTTP).

Mais même ces mécanismes de protection ont leurs limites. En effet, dans certaines attaques XSS, l'attaque se fait via la base de données. C'est pourquoi la recherche de code malveillant dans les entrées des utilisateurs est l'un des principaux mécanismes de sécurité dans la lutte contre les attaques XSS. Le contenu des commentaires est scanné à la recherche de chaînes de caractères suspectes et, si nécessaire, éliminé.

La sortie des données devrait également être sécurisée

Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <, > und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

Pour mettre cela en œuvre, des connaissances en programmation sont nécessaires. Cette protection de la sortie des données est facile à mettre en œuvre pour quelqu'un qui a ces connaissances.

Une bonne dose de scepticisme : comment les utilisateurs se protègent

Mais il n'y a pas que le site web lui-même, les clients (c'est-à-dire ton navigateur web) sont aussi concernés par les attaques XSS. De nombreuses attaques XSS peuvent être évitées par une utilisation critique et prudente des liens "étrangers". Il existe entre autres la possibilité d'utiliser les addons NoScript. Ceux-ci empêchent l'exécution des scripts, c'est-à-dire des lignes de code nuisibles qui, entre autres, volent des données.

Si tu veux être sûr, tu peux aussi éviter le Cross Site Scripting côté client en désactivant simplement le support JavaScript dans le navigateur. En effet, si ce soi-disant Active Scripting est désactivé, certains types d'attaques XSS n'ont plus aucune chance, car les applications nuisibles ne sont même pas lancées. Cependant, la plupart des sites Web modernes ne "fonctionnent" plus correctement ou, dans le pire des cas, ne fonctionnent plus du tout. Il faut donc trouver un équilibre entre la sécurité et la facilité d'utilisation. Si cette option t'intéresse, tu peux la trouver dans les paramètres de ton navigateur.

Conclusion

Les vulnérabilités XSS sont parfois les portes d'entrée les plus fréquentes pour les codes malveillants. Et souvent, une telle attaque constitue la base d'autres attaques, comme le spam, le phishing ou les attaques DDoS. Ton site Web est donc détourné et utilisé à d'autres fins. Le XSS n'est donc pas sans danger, d'où l'importance d'une protection adéquate.

Les XSS réfléchis et persistants sont particulièrement fréquents, car le Cross Site Scripting local est plus coûteux et plus difficile à mettre en œuvre. Les sites Web qui transmettent les données d'utilisateur saisies au navigateur Web sans vérifier la présence éventuelle de code malveillant sont particulièrement vulnérables. Mais trouver de telles failles n'est pas si simple. C'est en principe la tâche des fournisseurs de sécurité tels que sucuri et autres, qui développent en permanence leurs mesures de sécurité.

Mais bien sûr, il existe aussi la possibilité de se protéger contre ces attaques pour WordPress normal. Mettre à jour tous les composants de WordPress est, entre autres, une mesure simple mais très efficace. Si tu tiens tes plugins et tes thèmes à jour et que tu utilises un WAF, tu as déjà fait un grand pas dans la bonne direction. Si tu utilises en plus des listes blanches pour le code entrant et sortant, tu as déjà sécurisé ton site de manière excellente. Cependant, les deux dernières mesures ne sont pas faciles à mettre en œuvre sans connaissances en programmation.

En comparaison avec les attaques par force brute assez primitives, les attaques XSS plus complexes sont malheureusement encore relativement souvent couronnées de succès. Cependant, il y a beaucoup moins d'attaques complexes que d'attaques par force brute sur les sites WordPress. Cependant, tu dois rendre ces attaques aussi difficiles que possible. En effet, un piratage réussi ne coûte pas seulement du temps et de l'argent pour supprimer les scripts, mais peut aussi compromettre ta position dans les moteurs de recherche.