Comment éviter les failles Cross-Site Scripting (XSS)?
Les failles Cross-Site Scripting ou XSS, sont une des vulnérabilités concernant les applications web les plus connues et les plus utilisées comme vecteurs d'attaques.
Il existe trois formes basiques de vulnérabilités XSS:
- Le reflected XSS (XSS refléchi) : C’est la vulnérabilité la plus connue. Pour faire simple, en suivant une url piégée l'utilisateur arrivera sur une page dont le hacker contrôle le contenu. Si celui-ci a modifié des fonctionnalités de la page il pourra alors récupérer les données partagées par le visiteur (identifiant de connexion et mot de passe par exemple).
- Le stored XSS (XSS stocké) : Le XSS stocké est une saisie (input) utilisateur stockée dans l’application. Si les finalités d'attaques sont les mêmes que pour le XXS réfléchi, le stored XSS distribue l'attaque beaucoup plus largement. Cette faille est donc critique sur les sites à fort trafic.
- Le DOM XSS : C'est la modification du DOM ("Document Object Model", la représentation d'une site web dans un navigateur) qui permet aux hackers de récupérer les données des utilisateurs. De plus, les attaques DOM n’ayant pas besoin de passer par le serveur web, elles rendent les moyens de défense traditionnels, comme les pare-feux, inutiles.
Le Cross-Site Scripting a été utilisé, par exemple, contre Myspace, dans de nombreux incidents chez Twitter ainsi que pour une attaque d'envergure contre eBay en 2014. Le site avait d'abord été la cible d’autres attaques menant à l’exposition d’informations d’utilisateurs. Ces attaques ont été suivies d’une vaste exploitation de vulnérabilités XSS permettant de voler à nouveau des données utilisateurs. Même si eBay connait ses vulnérabilités, il avouait toujours souffrir de vulnérabilités XSS en 2017.
Fonctionnement du Cross-Site Scripting
Le Cross-Site Scripting se produit lors du passage d’un contexte où les données sont sécurisées à un contexte où elles sont mal interprétées. De ce fait, en ajoutant du contenu au site internet, un utilisateur peut prendre le contrôle et changer le comportement de l’application pour les autres utilisateurs.La forme la plus courante est l’introduction de code Javascript dans les requêtes (de formulaire, où les réponses sont souvent formatées), mais cela peut aussi être fait en ajoutant d’autres composants.
Il est important de retenir que la condition préalable à la réussite des attaques est qu’un utilisateur, ou que le navigateur de l’utilisateur, fournisse des informations à une application. Cette « entrée » est envoyée à un autre utilisateur dans le cadre d’une réponse.
Pour illustrer cela, sans regarder le code (plus technique), nous avons créé un exemple où les employés remplissent leur noms et l’équipe administrative indique le montant des salaires. Le paiement est automatique. Un utilisateur, Bob, décide de tromper le système. Alors que dans la base de données, tout va bien, les virements ne se passent pas comme d'habitude.
Le même problème se pose avec les applications web. Par contre, les données fournies par l’utilisateur sont interprétées en tant que JavaScript ou HTML par le navigateur web, et permettent en définitive à l’attaquant de contrôler l’application dans le navigateur. Et si l'attaque est correctement exécutée, les utilisateurs ne verront aucune différence sur la page web.
Avant une attaque Pendant une attaque
Cross-Site ScriptingSi une attaque est en cours, au lieu de soumettre les informations de connexion au site web, l’utilisateur les enverra au site du hacker. Comment éviter les vulnérabilités de Cross-Site Scripting
- Puisque les vulnérabilités concernent les sorties d'informations, la première chose est de sécuriser les entrées et les sorties et d'assurer la filtration des données lors de leur passage d’un statut à un autre, par exemple, lors de la lecture d’une réponse serveur ou d’une base de données.
- Une des premières choses, qui devrait d’ailleurs être un réflexe pour les équipes de sécurité, est de suivre les meilleures pratiques de sécurité. De coder rigoureusement, de segmenter le réseau et d’en contrôler les accès, d’éduquer leurs collaborateurs à la sécurité (ne pas ouvrir de emails suspects, ne pas partager d’informations bancaires, ou mettre en place des protocoles d'authentifications multiples), de vérifier et d'évaluer son réseau, et enfin de détecter les vulnérabilités et les corriger. Développeurs, suivez les conseils de l’OWASP et les meilleurs pratiques de sécurité de votre réseau et de vos fournisseurs d’infrastructures.
- Les DevOps peuvent limiter les XSS facilement en utilisant des process spécifiques fait pour échapper au Cross-Site Scripting, comme l’API de sécurité de l’OWASP (ESAPI). Il est également conseillé de mettre en œuvre des politiques de sécurité du contenu (CSP) en prévention. Si vous avez une application dynamique avec des mises à jour fréquentes, il est impératif d’analyser en continu la sécurité de l’application.
- Malgré cela, si vous disposez de nombreuses applications, vous souffrirez certainement de différentes vulnérabilités XXS. Le meilleur moyen de gérer la sécurité de votre réseau et de vos applications est d’évaluer et de gérer vos vulnérabilités ainsi que d’avoir une solution de sécurité adaptée à vos besoins et à votre infrastructure. Idéalement, la solution de sécurité devra surveiller en continu votre réseau, vous alerter quand une nouvelle vulnérabilité est détectée et vous donner les solutions pour y remédier. Vous pouvez aussi être aidé de professionnels de cybersécurité.
- Une fois le plan d’action sécurité en place, les applications critiques peuvent nécessiter des tests d'intrusion manuels poussés réalisés par des Ethical hackers. Agissant comme des hackers, ils vous montrent toutes vos failles réseaux et peuvent également cibler de potentielles vulnérabilités non atteintes par des scanners.
Les vulnérabilités Cross-Site Scripting sont connues, facile à détecter et à remédier donc agissez avant qu'il ne soit trop tard.