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.

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. En effet, elles sont référencées dans le top 10 de l’OWASP des risques de sécurité des applications web les plus critiques depuis la création de celui-ci et occupaient la première place du classement jusqu'en 2007. L'objectif des attaques par XSS est d’introduire du contenu ou des fonctionnalités dans un site internet afin de récupérer des données utilisateurs. Même si la menace est connue des DSI et RSSI, le problème persiste. En effet, les vulnérabilités XSS ont presque triplées en 2017. Alors que l'on détectait 630 vulnérabilités en 2016 ce chiffre est passé à 1863 en 2017. Pour l’OWASP, le « XSS est le 2ème problème le plus répandu dans le top 10 de l'association et se retrouve dans environ deux tiers des applications ». 
Les attaques par Cross-Site Scripting 
La vulnérabilité XSS est très répandue dans les systèmes d'information des entreprises. Sournoise, elle peut utilisée de multiples façons : grâce à elle, il est possible d’agir au nom des utilisateurs de l’application, de voler des identités, de rediriger le trafic ou encore d’injecter du faux contenu dans un site internet. Pour tenter de limiter les attaques, des mesures ont été mises en place ; dans les navigateurs par exemple, les cookies sont maintenant mieux protégés. Malheureusement, les cybercriminels se sont également adaptés. 
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.  
Les attaques XSS permettent, outre le piratage de comptes ou le vol de données sensibles (informations bancaires, informations d'identification), d'effectuer des téléchargements malveillants. On nomme le « défacement virtuel » (virtual defacement), la modification du contenu d'une page par les hackers (logo, faux contenu). Souvent la seule limite est la créativité des hackers.  
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.

Comme le montre l’exemple ci-dessus, le nom changé par l’utilisateur va rendre l'interprétation de l’information différente, et Bob obtiendra dix fois le salaire de ses collègues.   
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. 

Annonces Google