Les développeurs face à la sécurité : partage et apprentissage - Cross-Site Scripting (XSS)

Le Cross-site scripting (XSS) est un véritable casse-tête pour les professionnels de la sécurité depuis le début des années 2000. Malheureusement, des décennies plus tard, il reste l'une des menaces les plus courantes au niveau du code. Cette catégorie de vulnérabilité logicielle nous empoisonne la vie depuis bien trop longtemps, et une récente alerte de la CISA — dans le cadre de son mouvement « Secure-by-Design » — cherche à l'éradiquer une fois pour toutes. Ils se sont donné pour mission mondiale d'éliminer ces classes de vulnérabilités à grande échelle. Cette mise en lumière de la sécurité axée sur les développeurs peut réellement changer la donne, mais cela exigera un engagement de la part des entreprises intelligentes qui donnent à leurs développeurs les moyens de réussir en matière de sécurité.

Alors, qu'est-ce que le XSS, exactement ?

Les navigateurs web sont peut-être notre porte d'entrée vers tout ce que le web a de meilleur à offrir, mais ce n'est pas toujours une bonne nouvelle. Le comportement inhérent des navigateurs peut être un catalyseur de vulnérabilités de sécurité. À l'origine, les navigateurs faisaient aveuglément confiance au balisage qu'ils recevaient et l'exécutaient sans poser de questions. Tout allait pour le mieux jusqu'à ce que cette fonctionnalité soit détournée à des fins malveillantes... et, naturellement, les attaquants ont fini par trouver des moyens d'exploiter cette tendance pour servir leurs desseins malfaisants.

Le Cross-site scripting exploite la confiance des navigateurs et le manque de vigilance des utilisateurs pour dérober des données, pirater des comptes et défigurer des sites web ; c'est une vulnérabilité qui peut rapidement prendre des proportions critiques.

Examinons le fonctionnement des attaques XSS, les dommages qu'elles peuvent causer et comment les prévenir :

Comment fonctionne le XSS ?

Le XSS survient lorsqu'une entrée non fiable (souvent des données) est affichée sur une page mais interprétée à tort comme du code exécutable. Un attaquant peut insérer du code malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée qui, une fois renvoyé au navigateur, est exécuté au lieu d'être simplement affiché comme une donnée.

Comme mentionné précédemment, cette vulnérabilité est apparue en raison du fonctionnement fondamental des navigateurs, où il est difficile de distinguer les données du code exécutable. Le modèle opérationnel du web est le suivant :

1. L'utilisateur visite une page web
2. La page indique au navigateur quels fichiers charger et exécuter
3. Le navigateur exécute le contenu de la page sans poser de questions

Cette fonctionnalité est à l'origine de certaines des expériences web les plus interactives et impressionnantes dont nous profitons aujourd'hui. Le revers de la médaille est qu'elle a également conduit à des exploits et des vulnérabilités coûteux.

Lorsque des attaquants ajoutent leur script malveillant sur un site vulnérable, celui-ci est exécuté sans aucune vérification. Il n'y a ni analyse approfondie, ni mesures de détection en place.

Il existe trois types de XSS :

• XSS stocké
• XSS réfléchi
• XSS basé sur le DOM

Le XSS stocké survient lorsqu'un attaquant parvient à enregistrer de manière persistante un script malveillant dans un champ de données de l'application (par exemple, dans un champ stockant le numéro de téléphone mobile de l'utilisateur). Ce script douteux est ensuite envoyé au navigateur de chaque utilisateur à chaque fois que ce champ est affiché dans l'application.

Ce type d'attaque est fréquent sur les forums ou les systèmes de commentaires. Un attaquant insère le script malveillant dans un commentaire et, hop, chaque utilisateur qui consulte ce commentaire exécute le script à son insu.

Le XSS réfléchi survient lorsque l'entrée de l'utilisateur est renvoyée telle quelle au navigateur. Un exemple classique est une barre de recherche qui affiche « Vous avez recherché... » tout en récupérant les résultats.

Imaginez maintenant que la recherche fonctionne en plaçant le terme recherché dans l'URL sous forme de paramètres de requête. Un attaquant pourrait envoyer à sa victime un lien contenant le script malveillant intégré dans ces mêmes paramètres ; la plupart des utilisateurs ne remarqueraient rien.

La victime clique sur le lien et est redirigée vers un site de phishing où elle saisit involontairement son mot de passe. Sans qu'elle s'en rende compte, l'attaquant vient de dérober la clé de son compte.

Le XSS basé sur le DOM est une variante relativement récente. Il tire parti des structures de templating complexes présentes dans de nombreux frameworks d'interface utilisateur comme Angular et React.

Ces modèles permettent un contenu dynamique et des applications riches. S'ils sont mal utilisés, ils peuvent servir à exécuter des attaques XSS.

Voilà, vous avez maintenant une vue d'ensemble du XSS. Plongeons plus en détail dans la manière dont il peut être utilisé à des fins destructrices.

Pourquoi le XSS est-il si dangereux ?

Le XSS peut être utilisé pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et récupérer des données de session. En résumé, tout ce que JavaScript peut faire, les attaques XSS en sont également capables.

Voici trois exemples d'attaques XSS :

1. Les utilisateurs de Yahoo Mail ont vu leurs cookies de session volés via une attaque XSS en 2015.
2. Le ver Samy a été diffusé via une vulnérabilité XSS sur MySpace. Il reste le malware à la propagation la plus rapide de l'histoire, ayant touché un million d'utilisateurs en seulement 20 heures.
3. eBay permettait l'inclusion de scripts malveillants dans les descriptions de produits. Cela a conduit à des attaques XSS contre les utilisateurs d'eBay.

Les attaques XSS sont d'une simplicité trompeuse et pourtant très graves. Elles peuvent mener au vol de sessions, d'identifiants ou de données sensibles. Les atteintes à la réputation et la perte de revenus sont des conséquences majeures. Même une simple défiguration de site web peut entraîner des répercussions fâcheuses pour une entreprise.

Cependant, le XSS peut être vaincu par un expert en sécurité comme vous. La solution n'est pas complexe et l'industrie a fait d'immenses progrès depuis que le XSS est devenu une méthode d'exploitation courante.

Vous pouvez vaincre le XSS.

La clé pour vaincre le XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel l'entrée de votre utilisateur sera renvoyée au client et l'endroit où elle sera affichée : à l'intérieur du code HTML ou dans un extrait JavaScript.

Si l'entrée de l'utilisateur n'a pas besoin d'être renvoyée au navigateur, c'est encore mieux. Mais si c'est le cas, elle doit souvent être encodée en HTML. L'encodage HTML de la sortie indique au navigateur d'afficher le contenu tel quel sans l'exécuter.

La validation des entrées est également importante. Cependant, la validation et les listes blanches ne sont pas des solutions infaillibles. L'encodage va plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas intercepté par les stratégies de validation et de listes blanches sera traité par l'encodage.

De nombreux frameworks encodent désormais automatiquement les sorties HTML.
Angular, ASP.NET MVC et React.js sont des frameworks qui utilisent l'encodage HTML par défaut. Vous devez explicitement demander à ces frameworks de ne pas encoder en appelant une méthode spéciale.

La plupart des autres frameworks (comme Django et Spring) disposent de bibliothèques standard pour la prévention XSS que vous pouvez facilement intégrer à votre code.

Le plus grand défi consiste à apprendre à analyser toutes les manières dont une entrée utilisateur peut pénétrer dans un système afin de rester vigilant. Les paramètres de requête peuvent transporter des attaques, tout comme les paramètres POST. Suivez le flux de données dans toute votre application et ne faites confiance à aucune donnée provenant de l'extérieur.

Pensez comme un garde-frontière. Interceptez chaque donnée, inspectez-la et refusez-la si elle semble malveillante. Ensuite, encodez lors de l'affichage pour garantir que tout élément malveillant qui aurait échappé à la vigilance ne causera aucun problème.

Appliquez ces stratégies et vos utilisateurs seront protégés contre les attaques XSS. Consultez la Cheat Sheet de l'OWASP pour obtenir encore plus de conseils pour garder le contrôle sur vos données.

Contrez le XSS et faites monter en compétence votre expertise en sécurité.

Le XSS occupe la septième place du classement OWASP Top 10 2017 des risques de sécurité web. Il existe depuis un certain temps, mais il peut toujours apparaître et causer des problèmes à votre application si vous n'êtes pas vigilant.

La formation est essentielle pour aider les développeurs à adopter une mentalité axée sur la sécurité lors de la rédaction du code. Et cette formation est toujours plus efficace lorsqu'elle simule des applications réelles, dans les langages que les développeurs utilisent activement. Dans cette optique, pourquoi ne pas consulter nos Ressources d'apprentissage pour en savoir plus sur le XSS ? Ensuite, vous pourrez commencer la formation et la pratique qui mèneront à votre maîtrise.

Vous pensez être prêt à détecter et corriger les vulnérabilités XSS dès maintenant ? Relevez le défi sur la plateforme Secure Code Warrior.