Comment identifier les vulnérabilités Cross-Site Scripting (XSS)?

Cross-Site Scripting

 

Les failles XSS (Cross-Site Scripting, script inter-site en français), font parties des vulnérabilités applications web les plus communes. De même, les attaques XSS ne sont pas nouvelles. En effet, elles figurent dans le top 10 de l’OWASP des risques de sécurité des applications web les plus critiques depuis sa création et ont même été premières du classement en 2007. Les vulnérabilités XSS ont pour but d’introduire du contenu ou des fonctionnalités dans un site internet, et d’affecter de ce fait le visiteur du site et non l’application en elle-même. Même si la menace et les vulnérabilités sont bien connues, le problème persiste. Les attaques par Cross-Site Scripting comptaient notamment pour 8% de celles perpétrées contre les applications web sur le quatrième trimestre 2017 d’après le rapport de Akamai.

Les attaques par Cross-Site Scripting

XSS est une vulnérabilité très répandue. Pouvant paraître triviale, elle peut cependant, grâce aux techniques d’exploitations modernes, être utilisée de façons multiples : elle peut permettre d’agir au nom des utilisateurs de l’application, de voler des identités dans l’application, de rediriger le trafic ou même d’introduire du faux contenu dans un site Web d’entreprise. Tout comme l’exploitation s’est développée au fil des ans, des contre-mesures ont également été ajoutées (par exemple dans les navigateurs, les cookies étant protégés).  Malheureusement, les hackers se sont également adaptés.

 

Il y a trois formes basiques de vulnérabilités XSS

  • Le reflected XSS (XSS refléchi: C’est la vulnérabilité la plus connue et intervient lorsqu’un internaute effectue une requête et que le serveur ne renvoie pas une réponse sécurisée au navigateur. L’attaque est active uniquement pendant cette requête spécifique, obligeant le hacker à trouver un moyen de distribution (par exemple, par email, ou par liens provenant d’autres sites). Le danger est qu’un utilisateur peut suivre un url piégé qui injectera du code dans la page de résultat, permettant au hacker de contrôler le contenu de la page. De ce fait, le hacker sera en mesure de voler l’identité de l’utilisateur, d’envoyer du faux contenu sur le site internet ou de changer les fonctionnalités de connexion, permettant à l’attaquant de récupérer les données (identifiant, mot de passe) à la place du site.
  • Le stored XSS (XSS stocké) : A la différence du XSS réfléchi qui nécessite un moyen de distribution externe, le XSS stocké, ou persistant, est le résultat d’une saisie (input) de l’utilisateur stockée dans l’application, ayant le même impact négatif sur les utilisateurs exposés. En revanche, le XSS intégré à l’application permet donc d’affecter plus d’utilisateurs. Cette faille est donc critique pour un site à fort trafic.
  • Le DOM XSS : Le DOM ou « Document Object Model » est la représentation d’un site web dans un navigateur. Il est changé et modifié par le contenu dynamique, et via des vulnérabilités dans ces modifications. Le contenu des hackers peut être inclus par le navigateur lui-même également. De plus, les attaques DOM n’ont pas besoin de passer par le serveur web, rendant les moyens de défense traditionnels, comme les pare-feux, inutiles.

Les attaques XSS sont utilisées pour pirater des comptes, voler des données sensibles, comme des informations bancaires, ainsi qu’effectuer des téléchargements malveillants. Les hackers pratiquent également ce qui est appelé le « défacement virtuel » (virtual defacement) afin de modifier le logo, remplacer le contenu du site ou insérer du faux contenu dans un site d’actualités par exemple. Souvent, seule la créativité des hackers limite leurs possibilités.

Par exemples, des attaques par Cross-Site Scripting ont été utilisées contre le réseau social Myspace, dans de nombreux incidents de masse chez Twitter ainsi que pour une vaste attaque à l’encontre d’eBay en 2014. eBay avait initialement été la cible d’autres attaques menant à l’exposition d’informations d’utilisateurs. Ces attaques ont été suivies d’une large exploitation de vulnérabilité XSS permettant de répéter le vol des données utilisateurs. Même en connaissant les vulnérabilités, le site d’eBay avait avoué toujours souffrir de vulnérabilités XSS en 2017

 

Fonctionnement du Cross-Site Scripting

Le Cross-Site Scripting est, comme de nombreuses autres attaques contre les applications Web, une attaque qui se produit à partir 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 actifs tels que Silverlight ou Flash pour n’en nommer que quelques-uns.

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 immédiatement, ou plus tard, à un autre utilisateur dans le cadre d’une réponse.

Pour illustrer cela, sans regarder le code (pour ne pas embrouiller), nous avons créé un exemple où les employés remplissent leur noms et l’équipe administrative remplie le montant des salaires. Le paiement est automatique. Un utilisateur créatif, Bob, décide de tromper le système. Dans la base de données, tout va bien, mais quand les documents sont envoyés pour faire les virements, les choses changent rapidement.

Cross-Site Scripting exampleComme le montre l’exemple ci-dessus, le nom changé par l’utilisateur est maintenant soumis à une nouvelle sortie d’information. Ici, l’information est donc interprétée de manière différente, et Bob va obtenir 10 fois le salaire initial.

Le même problème se pose dans les applications web, mais dans ces cas-là, les données fournies par l’utilisateur sont interprétées en tant que JavaScript ou HTML par le navigateur web, et permettent donc à l’attaquant de contrôler l’application dans le navigateur.

L’un des dangers d’une attaque de Cross-Site Scripting correctement exécutée est les utilisateurs ne verront aucune différence sur le site internet.

Avant une attaque                                                                                              Pendant une attaque

Cross-Site ScriptingLa différence est, par exemple, qu’au lieu de soumettre les informations de connexion au site web, l’utilisateur enverra les enverra au site du hacker qui les stockera.

 

Le Cross-Site Scripting dans le top 10 de l’OWASP

Les failles XSS ont fait partie de l’OWASP TOP 10 depuis le début:
2004 – 4ème
2007 – 1er
2010 – 2ème
2013 – 3ème
2017 – 7ème

Le Cross-Site Scripting est classé A7 dans le dernier Top 10 de l’OWASP. Précédemment 3ème du classement en 2013, son risque tend à diminuer selon l’organisation. Cela est principalement dû aux efforts techniques mis en place par les navigateurs afin de protéger les sessions des utilisateurs. Il ne faut donc pas le voir comme une diminution du nombre de vulnérabilités. Surtout que, d’après Security Boulevard, les vulnérabilités XSS ont presque triplées en 2017. En effet, 630 vulnérabilités avaient été détectées en 2016 contre 1863 en 2017. La même étude explique également que le XSS représentait 8% des cyberattaques de 2017.

Cross-Site Scripting and web app vulnerabilities

Graphique : Nombres et types de vulnérabilités du Top 10 de l’OWASP entre 2014-2017 (Security Boulevard)

Dans le classement 2017, l’OWASP estime l’exploitabilité du Cross-Site Scripting comme élevée ainsi que la détectabilité comme difficile : « XSS est le 2ème problème le plus répandu dans le top 10 de l’OWASP et se retrouve dans environ deux tiers des applications ».

Enfin, d’après le tableau de l’OWASP, l’impact du Cross-Site Scripting est « modéré pour les XSS réfléchis et DOM et sévère pour les XSS stockés ». Comme les attaques par Cross-Site Scripting permettent l’accès total d’un utilisateur à un système, la raison pour laquelle l’impact est considéré comme modéré est dû à la difficulté de distribuer l’attaque à un utilisateur authentifié. Mais si un hacker résout le problème de distribution, ou si une application fortement fréquentée est attaquée, alors il n’y a plus de barrières. Et pour n’importe quel utilisateur, la réussite d’une attaque est critique.

 

Comment éviter les vulnérabilités de Cross-Site Scripting

1. Puisque les vulnérabilités Cross-Site Scripting se produisent par la sortie d’information vers l’utilisateur, la première chose est de prévenir l’exploitation en assainissant les entrées et sorties d’informations. Le seul moyen de construire une application robuste est 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.

2. Promouvoir les bases et les valeurs de la sécurité est indispensable. 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 ses équipes à la sécurité (ne pas ouvrir de mails suspects, ne pas partager d’informations bancaires, ou mettre en place des authentifications multiples). Vérifier et évaluer son réseau, chercher les vulnérabilités et les patcher quand vous en trouvez. Développeurs, suivez les conseils de prévention de l’OWASP et les meilleurs pratiques de sécurité de votre réseau et de vos fournisseurs d’infrastructures.

3. 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 ou mettre en œuvre des politiques de sécurité du contenu (CSP) en défense. Si vous avez une application dynamique avec des mises à jour fréquentes, il est impératif d’avoir un programme de sécurité continu permettant un audit de l’application, comme le propose nos solutions AppsecScale et SWAT par exemple.

4. Malgré vos efforts, si vous disposez d’une gamme d’applications conséquente, vous souffrirez certainement de multiples 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 et 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é.

5. Une fois le plan d’action sécurité en place, les applications critiques peuvent nécessiter l’intervention supplémentaire de tests de pénétration (Ethical hackers) afin de réaliser un audit de l’application. Les ethical hackers réalisent un travail remarquable, agissant comme des hackers pour vous montrer toutes vos failles réseaux. Ils peuvent également cibler de potentielles vulnérabilités non atteintes par des scanners de vulnérabilités.

Les vulnérabilités de Cross-Site Scripting sont connues, facile à détecter et à remédier donc ne tomber pas dans le piège. Si vous voulez de l’aide ou en savoir plus sur votre niveau de sécurité, contactez nous. Et découvrez dés à présent nos solutions de sécurité des applications web pour protéger vos réseaux internes et externes ou nos outils de management des vulnérabilités.

La sécurité des applications est un sujet complexe. Nos équipes sont également à votre disposition pour réaliser des audits et vous permettre de trouver la solution la plus adaptée à vos besoins et votre budget cybersécurité.

Tester vos vulnérabilités Cross-Site Scripting dès maintenant

Leave a Reply

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.