Empêcher l'exécution de scripts malveillants et le vol d'informations sur les utilisateurs en bloquant les entrées HTML, en assainissant les données, en sécurisant les cookies et en déployant des pare-feu d'applications web (WAF).
Cet article s'articule autour des points suivants :
Copier le lien de l'article
Le cross-site scripting (XSS) est une tactique par laquelle un acteur malveillant injecte du code malveillant via un ou plusieurs scripts web dans un site web ou une web application légitime. Lorsqu'un utilisateur charge le site web ou exécute l'application web, ces scripts s'exécutent dans le navigateur de l'utilisateur.
Les scripts peuvent effectuer diverses actions malveillantes, telles que le vol des cookies HTTP des utilisateurs, des jetons de session ou d'autres informations sensibles. Un acteur malveillant peut utiliser ces informations pour se faire passer pour des utilisateurs et accéder sans autorisation à des comptes sur différentes plateformes telles que des plateformes de médias sociaux ou des sites web bancaires. En outre, les scripts peuvent endommager les sites web, rediriger les utilisateurs vers des sites malveillants ou extraire des données confidentielles d'une application web .
Pour en savoir plus, voir Qu'est-ce que le cross-site scripting?
Les deux types d'attaques XSS les plus répandus sont le XSS par (non persistant) et le XSS stocké (persistant).
Les attaques XSS par réflexion peuvent se produire lorsqu'un site web légitime ne parvient pas à valider ou à assainir les entrées d'un utilisateur. Ces attaques commencent souvent par une opération d'ingénierie sociale, au cours de laquelle les acteurs malveillants envoient des e-mails de phishing ou laissent des messages dans des publications de forums en ligne avec un lien sur lequel les utilisateurs sont incité à cliquer. En général, le lien inclut l'URL d'un site web légitime auquel est ajouté du code malveillant.
Lorsqu'un utilisateur clique sur le lien, son navigateur envoie une requête au site web légitime, qui transmet par réflexion le code injecté au navigateur de l'utilisateur. Le site web ne parvenant pas à assainir correctement les données entrées, le script malveillant s'exécute dans le navigateur de l'utilisateur.
Le code peut copier les cookies de l'utilisateur et les envoyer à l'acteur malveillant. Si l'acteur malveillant récupère un cookie de session, il peut prendre le contrôle de la session, et ainsi procéder à des achats frauduleux, voler des informations bancaires ou publier des spams sur des plateformes de médias sociaux, entre autres actions malveillantes.
Ce type d'attaque XSS est qualifié de « réfléchie » car le script malveillant est réfléchi sur le serveur web et exécuté dans le navigateur de l'utilisateur. Elle est également appelée « non persistante » car le script ne s'exécute dans le navigateur de l'utilisateur que lorsque la page est chargée, et non de manière permanente.
Les attaques XSS stockées sont plus graves que les attaques XSS par réflexion ou réfléchies. Dans le cas du XSS stocké, un script malveillant est stocké en permanence sur le serveur cible.
Les acteurs malveillants réalisent généralement cette forme de XSS en intégrant un script malveillant dans un champ de formulaire, comme une zone de commentaire, un profil d'utilisateur ou tout autre champ de saisie qui accepte et stocke le contenu de l'utilisateur. Une fois la publication, le commentaire ou le formulaire soumis, le script est injecté dans l'application web et enregistré dans la base de données de l'application web. Lorsque d'autres utilisateurs chargent la page affectée, le script stocké est exécuté dans leur navigateur. Comme dans le cas des attaques XSS réfléchies, le script peut alors voler des cookies ou d'autres informations utilisateur, qui sont ensuite être renvoyés à l'acteur malveillant.
Ce type de XSS est également appelé « persistant » car l'exécution se produit à chaque accès à la page. C'est également ce qui rend les attaques XSS stockées particulièrement dangereuses : elles peuvent affecter un grand nombre d'utilisateurs sans qu'aucune interaction autre que la simple visualisation d'une page web ne soit nécessaire.
Les utilisateurs individuels peuvent prendre plusieurs mesures pour réduire le risque d'attaques XSS :
Les attaques XSS commençant souvent par des opérations de phishing ou d'autres tactiques d'ingénierie sociale, les utilisateurs doivent apprendre à identifier les e-mails et les messages suspects. S'ils avertissent la bonne équipe informatique ou de sécurité, les utilisateurs continuent à stopper les attaques XSS et à résoudre d'autres problèmes de sécurité.
Si les utilisateurs voient un lien dans un forum en ligne ou dans un publication dans un réseau social d'une personne qu'ils ne connaissent pas ou en qui ils n'ont pas confiance, ils doivent y réfléchir à deux fois avant de cliquer sur le lien. Même si le lien semble légitime, les utilisateurs doivent rester vigilant. De nombreux liens qui déclenchent des attaques XSS semblent légitimes car ils contiennent des URL légitimes. Cependant, les utilisateurs doivent examiner le lien dans son ensemble, y compris tout ce qui se trouve après le .com, .org, .gov, ou tout autre suffixe. Un texte inattendu après l'adresse de la page peut correspondre à du code malveillant.
Les développeurs peuvent jouer un rôle essentiel dans la prévention des attaques XSS en mettant en place quelques bonnes pratiques essentielles :
Les développeurs peuvent mettre en place des règles qui empêchent les utilisateurs de publier des données sur une page ou dans un formulaire lorsqu'elles ne répondent pas à certains critères. Par exemple, si un formulaire invite à saisir un numéro de sécurité sociale ou un numéro de téléphone, les développeurs peuvent créer une règle selon laquelle cette entrée ne doit contenir que des chiffres, des tirets ou des parenthèses. Pour une prévention des attaques plus robuste, les développeurs peuvent définir des règles de validation qui rejettent explicitement les balises ou les caractères couramment utilisés dans les attaques XSS, tels que les balises < script >.
Les développeurs peuvent également empêcher les utilisateurs d'inscrire du code HTML dans les commentaires, les messages et les entrées de formulaires. Le contenu HTML peut être un moyen de publier des scripts malveillants ou de dissimuler des liens vers des URL qui contiennent du code malveillant.
Si les entreprises souhaitent permettre aux utilisateurs de publier du contenu enrichi, comme du texte ou des images mis en forme, elles peuvent intégrer Markdown (un langage de balisage léger) ou activer la mise en forme d'un texte enrichi au sein d'un éditeur WYSIWYG (« Ce que vous voyez correspond à ce que vous obtenez »). Ces deux méthodes constituent des solutions plus sûres pour la prise en charge de contenu enrichi.
Les développeurs peuvent prévenir les dommages liés aux attaques XSS en mettant en œuvre une procédure d'examen des données après qu'elles ont été publiées sur le serveur web, mais avant qu'elles ne soient affichées à un autre utilisateur. Même si les développeurs autorisent l'utilisation du code HTML, par exemple, ils peuvent assainir toutes les saisies HTML et éliminer tout le code malveillant avant qu'il ne s'exécute dans un navigateur.
L'encodage et l'ajout de préfixe d'échappement fonctionnent selon un principe similaire. L'idée est de transformer les scripts malveillants ou tout autre code présent dans les saisies de l'utilisateur en texte ordinaire avant toute inscription sur une page. L'encodage de sortie convertit le code dans un format différent ; « l'échappement » ajoute des caractères spéciaux au code (comme des barres obliques inverses ou des guillemets) Dans les deux cas, les navigateurs interprètera la saisie comme du texte et non comme un code à exécuter. Tandis que l'assainissement filtre le code, l'encodage et l'ajout de caractères d'échappement préservent le code tout en le rendant inoffensif.
Les développeurs doivent intégrer la sécurité tout au long du développement de l'application web. Par exemple, ils doivent examiner le code, en se concentrant notamment sur les zones dans lesquels les saisies des utilisateurs sont acceptées et affichées. Ils doivent également procéder à une modélisation des menaces et à des tests pour identifier les vulnérabilités avant que les applications ne soient mises en ligne.
Les équipes de sécurité peuvent mettre en œuvre plusieurs bonnes pratiques pour prévenir les attaques XSS et y apporter une réponse rapide :
Les équipes de sécurité peuvent adopter plusieurs mesures pour vérifier que les serveurs web sont correctement configurés afin de bloquer les scripts malveillants et d'empêcher les acteurs malveillants de voler les cookies des utilisateurs :
Mettre en œuvre une politique de sécurité du contenu : les développeurs et les équipes de sécurité doivent travailler ensemble pour définir des politiques de sécurité du contenu (CSP) strictes pour le site web et l'application web, et les appliquer aux serveurs web . Une CSP est une couche supplémentaire de sécurité qui peut détecter et atténuer certains types d'attaques. Pour prévenir les attaques XSS, elle limite les scripts pouvant être exécutés. Les serveurs web peuvent être configurés de façon à renvoyer des en-têtes de réponse HTTP CSP qui empêchent les navigateurs de charger des scripts nuisibles.
Sécuriser les cookies : les équipes de sécurité peuvent définir des règles spéciales régissant la manière dont les serveurs web traitent les cookies, afin de réduire le risque de vol de cookies. Par exemple, elles peuvent associer les cookies à des adresses IP d'adresses particulières. Étant donné que la plupart des utilisateurs ont une adresse IP dynamique, les connexions entre une adresse IP et les cookies ne durent pas longtemps. Par conséquent, les acteurs malveillants ne sont pas en mesure de voler ni d'utiliser ces cookies.
Qui plus est, les équipes de sécurité peuvent empêcher le JavaScript d'accéder aux cookies. Pour y parvenir, elles peuvent par exemple ajouter l'indicateur HTTPOnly aux cookies au moment de les générer. L'indicateur précise que les cookies peuvent contenir des informations sensibles concernant l'utilisateur, telles qu'un jeton de session ou des identifiants d'authentification. Un navigateur qui prend en charge le drapeau HTTPOnly ne révélera pas ces informations.
Un pare-feu d'applications web (WAF) peut constituer une ligne de défense essentielle contre XSS les attaques. Agissant comme un proxy inverse placé en amont de l'application web, un pare-feu WAF protège ces applications en surveillant et en filtrant le trafic HTTP circulant entre l'application et Internet. Les entreprises peuvent définir des règles de pare-feu WAF afin d'inspecter les URL à la recherche de scripts malveillants et d'empêcher que ces derniers ne soient réfléchis pour les utilisateurs. Les solutions de pare-feu WAF avec apprentissage automatique offrent une protection encore plus robuste en détectant les tentatives de contournement des règles et en identifiant les variantes d'attaques connues.
Étant donné que de nombreuses attaques XSS commencent par du phishing, les équipes de sécurité doivent renforcer les défenses contre les attaques par phishing. En plus d'apprendre aux utilisateurs comment identifier les e-mails et les messages suspects, les équipes de sécurité peuvent mettre en œuvre des fonctionnalités de sécurité destinées à bloquer les spams, utiliser un service d'isolement de navigateur pour empêcher l'exécution de logiciels malveillants, installer une passerelle web sécurisée (SWG) pour empêcher les utilisateurs de télécharger fichiers malveillants, et déployer des outils de sécurité des e-mails permettant de détecter et de bloquer les tentatives de phishing en temps réel.
Les équipes de sécurité doivent tester les vulnérabilités dans les environnements de production. Les équipes peuvent effectuer des tests de pénétration manuels ou utiliser des scanners XSS automatisés.
Malgré d'importants efforts de prévention, les entreprises peuvent encore être la cible d'attaques XSS. La mise en place d'un plan de réponse aux incidents est essentielle pour permettre un rétablissement rapide de la sécurité. Cette offre doit comprendre des stratégies de surveillance des activités des applications web et de mesures à prendre lorsque des événements suspects se produisent. Les équipes doivent ensuite analyser les causes profondes et identifier les méthodes d'attaque. Une fois l'attaque terminée, elles doivent appliquer les enseignements dégagés pour renforcer les fonctionnalités de sécurité, mettre à jour les politiques et corriger les vulnérabilités des applications web .
Cloudflare propose plusieurs produits et fonctionnalités qui peuvent aider les entreprises et les utilisateurs à prévenir les attaques XSS :
En savoir plus sur le par-feu WAF de Cloudflare.