Comment vérifier si votre système WordPress est sécurisé contre les attaques XSS

Dans le monde, près de 48 % de tous les sites Web sont vulnérables au cross-site scripting (XSS). Dans le monde, presque exactement 25% de tous les sites Web utilisent la plate-forme WordPress.

Il s’ensuit que dans le diagramme de Venn des sites Web vulnérables à XSS et des sites Web exécutant la plate-forme WordPress, le chevauchement doit être assez important.

Ce n’est pas un coup sur la plate-forme elle-même. L’équipe WordPress a fait de la sécurité une partie intégrante de son énoncé de mission et corrige de manière agressive les vulnérabilités chaque fois qu’elles sont connues. Pourtant, cela n’empêche pas les gens de coder des thèmes non sécurisés ou d’installer des plugins non sécurisés. Ces problèmes sont les deux principales portes d’entrée des attaques XSS sur les sites WordPress, et cet article explique comment les arrêter.

Introduction aux scripts intersites

Voyons d’abord comment les attaques XSS sont menées. Il existe plus d’un type d’attaque XSS, je vais donc commencer par une définition simplifiée. En règle générale, les attaques XSS commencent par des entrées non épurées – formulaires de commentaires, zones de commentaires, barres de recherche, etc. Ces attaques varient considérablement en sophistication. Vous savez de quoi je parle: «Merci pour cet excellent article. Au fait, voici mon site sur lequel je gagne 5 000 $ par semaine en travaillant à domicile : www.only-an-idiot-would-click-this-link.co.uk. »

D’une certaine manière, les commentaires de spam sont l’exemple parfait d’une attaque XSS. Une entité malveillante subvertit l’infrastructure de votre site (la zone de commentaire) pour placer son contenu (le lien malveillant) sur votre site. Bien qu’il s’agisse d’un bon exemple illustratif, une attaque XSS plus réaliste sera beaucoup plus subtile. Un commentaire de spam prend environ cinq secondes à quelqu’un pour créer. Une attaque XSS est quelque chose sur laquelle un véritable hacker passera un peu plus de temps.

Un vrai chapeau noir essaiera de tirer parti de tous les aspects de votre site qui soumettent des données au serveur, les utilisant essentiellement comme un éditeur de texte miniature. Si vos entrées ne sont pas protégées, cela signifie qu’elles peuvent littéralement prendre leur code et forcer votre application à l’exécuter et à s’afficher dans le navigateur d’un utilisateur (et cela peut inclure votre navigateur). Contrairement aux commentaires de spam, seul un examen détaillé du code modifié de votre site ou un examen approfondi des interactions du site Web peut révéler une violation. Comme on peut l’imaginer, il n’y a pas de fin au nombre de choses peu recommandables qui pourraient résulter d’une telle violation.

Le vandalisme simple est un résultat relativement courant des attaques XSS, ce qui fait que vos utilisateurs voient des images grotesques ou de la propagande politique à la place de votre contenu. Les spécialistes du marketing ayant peu de plans à long terme ou des préoccupations éthiques les utiliseront pour faire de la publicité auprès des gens contre leur gré. Une attaque plus nuancée et subtile pourrait voler les identifiants de connexion de vos utilisateurs. Si l’un d’eux a des privilèges d’administrateur, toutes les informations personnelles que vous stockez sur votre site peuvent être récupérées. Alternativement, ils peuvent utiliser l’attaque XSS initiale comme levier pour ouvrir votre site et installer des logiciels malveillants encore plus avancés.

Arrêter les attaques

Si vous êtes une personne raisonnablement avertie en matière de code et que vous êtes l’unique propriétaire d’un site WordPress relativement petit, les pratiques de codage sécurisé seront probablement le meilleur moyen de verrouiller votre site contre les attaques de script intersite. J’inclus cette mise en garde car si vous faites partie d’une organisation plus grande exécutant une application plus complexe, il ne vous sera peut-être pas humainement possible de trouver tous les domaines où un attaquant malveillant pourrait injecter du code. Les sites Web modernes peuvent être à grande échelle, et il pourrait vous incomber d’embaucher un professionnel chevronné et de consacrer votre temps à d’autres activités pour rendre votre site Web encore meilleur pour vos lecteurs.

Un autre avertissement est que si vous n’êtes pas particulièrement averti en matière de code et que quelqu’un d’autre crée votre site pour vous, ne présumez pas qu’il a utilisé des pratiques de codage sécurisées. Même les développeurs les plus expérimentés sont connus pour laisser la sécurité de côté ou faire des erreurs mineures sans que quelqu’un d’autre vérifie leur travail. D’autres développeurs peuvent tout simplement ne pas savoir ce qu’ils font en termes de sécurité, et d’autres continuent de passer sous silence la sécurité pour sauver du temps pour eux (malgré le manque de professionnalisme à cet égard). En résumé, assurez-vous d’embaucher un professionnel réputé qui ne lésine pas sur le développement et la protection de votre site Web.

Cette préoccupation étant exprimée, l’une des premières et des plus simples choses que vous puissiez faire pour empêcher les scripts intersites est de valider les données des utilisateurs.

Disons que vous avez un formulaire d’inscription sur votre site et que ce formulaire demande à l’utilisateur de saisir son nom. Un utilisateur malveillant pourrait plutôt taper quelque chose comme :

Cela pourrait, par exemple, amener la prochaine personne qui visite cette page à envoyer une copie de ses cookies à un attaquant.

Vous pouvez voir que dans cet exemple, la chaîne de code ci-dessus ne ressemble en rien au nom de quelqu’un. Votre serveur ne le sait pas, mais en utilisant quelques paramètres définis, vous pouvez lui apprendre. Par exemple, vous pouvez dire à ce champ de rejeter les caractères spéciaux, tels que ,() et ; (ils ne sont pas particulièrement nécessaires dans une section de commentaires). Vous pouvez indiquer à ce champ que le nom d’une personne ne contient probablement pas de chiffres. Si vous êtes prêt à être un peu draconien, vous pouvez indiquer à ce champ de rejeter les entrées de plus de quinze caractères (ou vous pouvez modifier les valeurs comme vous le souhaitez). Prendre ces mesures limitera considérablement la quantité de dégâts qu’un attaquant peut faire avec un champ particulier.

Même avec la validation des données, il peut y avoir des formulaires ou des champs où vous ne pouvez pas limiter de manière réaliste le type de caractères utilisés, comme dans un formulaire de contact ou un champ de commentaire. Ce que vous pouvez faire, c’est nettoyer les données. Ce processus rend impossible l’exécution de HTML dans un champ donné, convertissant tout ce qui pourrait être reconnaissable comme un morceau de code exécutable en caractères non codants. Par exemple, un lien hypertexte n’apparaîtra pas là où il pourrait en exister un.

Enfin, il existe des cas dans lesquels votre site peut finir par afficher des données dangereuses pour les utilisateurs. Supposons que quelqu’un rédige un commentaire malveillant sur l’une de vos pages, qui est ensuite indexé par la fonction de recherche de votre site Web. Chaque fois qu’un de vos utilisateurs effectue une recherche, ce code malveillant est exécuté lorsque son navigateur charge les résultats de la recherche. Ceci est évité en échappant aux données, ce qui garantit que lorsque votre site fournit des données à un utilisateur, le seul code qui s’exécute est le code que vous souhaitez exécuter.

Pour en savoir plus sur la validation des données, la désinfection des données et l’échappement des données, le WordPress Codex dispose d’une excellente ressource. Il expliquera les concepts ci-dessus en détail et donnera plus d’exemples qui peuvent être appliqués universellement.

Autres méthodes

Les grandes entreprises ont de plus grands sites Web; c’est un fait. Peut-être que des milliers de personnes utilisent votre site chaque jour. Peut-être qu’au lieu de formulaires et de champs standard, il existe également des animations, divers portails, des parties écrites en Java, etc. Même si vous gardez une trace de tout cela, il y a peut-être un jour zéro dans l’une de vos applications, et vous n’avez aucun moyen de vous défendre.

Dans une situation comme celle-ci, si vous avez l’influence et le budget nécessaires pour le faire, je vous recommande d’investir dans un pare-feu d’application Web (WAF). Un bon WAF aura des règles de corrélation qui identifient et bloquent automatiquement les chaînes HTML qui sont le plus souvent associées aux attaques par injection de code. Ils peuvent également vous avertir lorsque des applications commencent à exfiltrer des données alors qu’elles ne sont pas censées le faire ou qu’elles le font dans un volume inhabituel, aidant ainsi à se défendre contre les attaques zero-day et autres menaces avancées. Un WAF n’est pas une solution miracle, mais c’est un outil inestimable pour les professionnels de la sécurité et les propriétaires de sites Web qui souhaitent protéger des applications complexes.

Il existe également un certain nombre de plugins qui prétendent se défendre contre les attaques XSS. En fait, je ne les recommande pas. Plutôt que de réduire les risques, bon nombre de ces plugins ne représentent qu’une autre surface d’attaque à exploiter par un pirate informatique. Même l’un des plugins de sécurité les plus connus et les plus utilisés, Akismet, s’est avéré vulnérable aux attaques XSS l’année dernière. Lorsqu’il s’agit de détourner les attaques XSS, ne comptez pas sur des demi-mesures. Développez les compétences nécessaires et utilisez l’ensemble d’outils approprié pour assurer la sécurité de votre site Web.

Autres applications pratiques

Ces informations peuvent être un peu complexes pour les non-initiés, mais je détesterais que les gens soient découragés par la complexité potentielle de ces informations. Si une attaque XSS se produit, vous pouvez être certain que le nettoyage des conséquences d’un tel événement sera beaucoup plus complexe que d’apporter les modifications à votre site Web. Nettoyer les coûts de réputation de votre site Web (les lecteurs réguliers fuiront votre site Web assez facilement) sera un problème supplémentaire dont vous ne voulez pas avoir à vous soucier.

Même si vous demandez à quelqu’un d’autre de gérer le développement et la sécurité de votre site Web pour vous, faites ce que vous pouvez pour au moins être en mesure de répondre à une urgence et de savoir où se trouvent vos points faibles. Savoir comment vérifier votre système sera une compétence essentielle à long terme et sera la base d’autres sujets de sécurité et de projets de développement de sites Web. Tout est interconnecté en ligne et bien que les attaques XSS puissent être une chose des dernières années sur toute la ligne (aussi peu probable que cela soit), connaître les tenants et les aboutissants de votre site Web ne sera jamais obsolète.

Dernières pensées

Le paysage de la sécurité Internet change constamment. Vous ne pouvez jamais être entièrement certain de la manière dont une attaque XSS pourrait apparaître ou de la manière dont elle pourrait être utilisée contre vous, mais vous vous devez, à vous-même et à vos lecteurs, de vous assurer que vous faites tout ce qui est en votre pouvoir pour les arrêter. Continuez à vous informer sur cette menace et vérifiez régulièrement (je recommanderais au moins une fois par mois) tout développement pertinent dans le monde de la cybersécurité.

Cela ne signifie pas non plus que vous pouvez ignorer les autres menaces. L’accès au réseau public nécessite toujours l’utilisation d’un VPN pour être sûr. Vous ne pouvez pas négliger la sécurité de tout ordinateur que vous utilisez pour accéder à votre site Web. Les informations de connexion doivent encore être modifiées souvent et être à l’abri des attaques par force brute. Les attaques XSS sont brutales, mais elles ne sont pas la seule menace à surveiller.

Il peut également vous incomber de partager ces informations (ou même cet article) avec vos pairs et les parties intéressées afin de propager la résistance contre ces types d’attaques. Bien que vous ne puissiez pas en faire trop par vous-même, si suffisamment de personnes se protègent correctement, nous pourrions voir une diminution générale de ces types d’attaques alors que les pirates tentent de trouver une autre façon de profiter des internautes pauvres.

Avez-vous vous-même des idées sur la façon de vérifier les attaques XSS et de vous défendre contre elles à l’avenir ? Existe-t-il d’autres stratégies de détection et de suppression que vous utilisez vous-même pour lutter contre cette menace ? Y a-t-il des outils que vous recommanderiez à vos collègues lecteurs? Si tel est le cas, veuillez laisser un commentaire ci-dessous et poursuivre cette importante conversation avec vos collègues lecteurs.