Qu'est-ce que le Cross-Site Scripting ? Comment prévenir les attaques XSS

Quand nous pensons aux cyberattaques, nous pensons aux violations de données, aux virus et aux logiciels malveillants, mais avez-vous déjà entendu parler du cross-site scripting, alias les attaques XSS ? Probablement pas. Même si c'est l'une des menaces les plus notoires et courantes dans les applications web que nous utilisons aujourd'hui. Alors, qu'est-ce que c'est ?

Les applications web permettent souvent aux utilisateurs d'interagir avec elles en soumettant des données via des formulaires ou d'autres champs de saisie. Les pirates peuvent exploiter cette vulnérabilité pour injecter des scripts malveillants si l'application ne valide et ne nettoie pas correctement ces saisies utilisateur.

Les attaques XSS posent des risques importants, notamment des pertes financières, des violations de données, des systèmes compromis, des réputations endommagées et des conséquences juridiques. Les développeurs et les propriétaires de sites web doivent mettre en œuvre des mesures de sécurité robustes et installer des outils comme les pare-feu d'application web et les logiciels de gestion unifiée des menaces pour prévenir les vulnérabilités XSS.

Comment fonctionne le cross-site scripting (XSS) ?

Commençons par apprendre la politique de même origine pour comprendre comment fonctionnent les attaques de cross-site scripting.

Politique de même origine

La politique de même origine est un mécanisme de sécurité intégré dans les navigateurs web qui empêche le vol de données. Par exemple, le contenu d'un site est autorisé à utiliser des cookies et d'autres ressources sur le navigateur web d'un utilisateur. Selon la politique de même origine, le contenu de toute URL ayant le même identifiant de ressource uniforme (URI), nom d'hôte et numéro de port partage également ces autorisations. Si ces trois attributs diffèrent, le site a besoin d'une autorisation distincte.

Lorsque la politique de même origine n'est pas strictement appliquée à l'aide de mesures de sécurité web comme la validation et la désinfection des saisies utilisateur, cela crée des vulnérabilités dans les applications web.

Les attaques de cross-site scripting utilisent généralement JavaScript, mais tout langage de programmation côté client, comme PHP, le langage de balisage hypertexte (HTML) et .NET, fonctionne également.

L'anatomie d'une attaque de cross-site scripting

Passons par un exemple pour comprendre comment fonctionne une attaque XSS :

Disons qu'il y a une application web avec une section de commentaires où les utilisateurs peuvent poster des messages qui sont affichés sur le site web. Cependant, la section de commentaires de l'application a une vulnérabilité qui ne valide ni ne désinfecte correctement la saisie utilisateur avant qu'elle ne soit affichée.

Un attaquant identifie cela et exploite la faille en injectant du code JavaScript nuisible dans l'une des sections de commentaires des pages web. Ils postent un commentaire avec le contenu suivant :

Maintenant, au lieu de traiter le code injecté comme du texte brut, l'application non protégée affiche le commentaire sur le site web sans encodage ou validation appropriés. Lorsque d'autres utilisateurs visitent la page web qui contient ce commentaire, leurs navigateurs interprètent le code JavaScript injecté comme faisant partie du contenu du site web et l'exécutent.

En conséquence, une boîte d'alerte apparaît, affichant le message, "Ceci est une attaque de cross-site scripting (XSS) malveillante, attention !" 

Si cela n'était pas assez grave, les conséquences de l'attaque pourraient être bien plus sévères, selon les intentions du cybercriminel. Les acteurs de la menace peuvent utiliser le script exécuté pour voler des informations sensibles, rediriger les utilisateurs vers des sites de phishing, enregistrer les frappes, capturer les soumissions de formulaires ou compromettre le système en téléchargeant et exécutant des logiciels malveillants.

Attaque XSS vs. CSRF vs. injection SQL

Il est facile de confondre XSS avec l'injection SQL et la falsification de requête intersite (CSRF) car les trois exploitent les vulnérabilités des applications web. Cependant, ce sont des menaces de sécurité web distinctes et elles varient dans leur nature et le type d'attaques qu'elles engendrent.

• Les attaques XSS injectent des codes malveillants dans un site web de confiance et font en sorte que le navigateur web de l'utilisateur l'exécute involontairement.
• La falsification de requête intersite trompe un utilisateur autorisé en utilisant des techniques d'ingénierie sociale comme le phishing pour faire des requêtes malveillantes au nom de l'utilisateur.
• Les attaques par injection SQL injectent du code SQL malveillant dans la couche de base de données d'une application web pour accéder à des données qui n'étaient pas censées être affichées.

Historique des attaques XSS

Les vulnérabilités XSS remontent aux débuts d'internet. À mesure que les pages web devenaient plus interactives avec le lancement de JavaScript en 1995, les développeurs ont commencé à accepter les saisies utilisateur via des formulaires et d'autres éléments coopératifs sur les pages web.

Cependant, les développeurs n'ont pas efficacement validé et désinfecté les saisies utilisateur et ont exposé des vulnérabilités que les attaquants pouvaient – et ont – exploitées. Une équipe d'ingénieurs en sécurité de Microsoft a d'abord inventé le terme "cross-site scripting" pour ces attaques, et au fil du temps, sa définition s'est élargie pour inclure d'autres types d'attaques par injection de code.

Avant 2005, la plupart des chercheurs en sécurité se concentraient sur d'autres menaces de sécurité web comme les attaques par débordement de tampon, les vers, les botnets ou les virus. Cela jusqu'à ce que le célèbre ver Samy sur MySpace infecte plus d'un million d'utilisateurs en 24 heures en utilisant une attaque XSS, démontrant son potentiel d'échelle et d'impact.

Suite au coup dévastateur, la communauté de la cybersécurité a fait des efforts louables pour résoudre les vulnérabilités XSS. Mais même alors, cela reste une menace persistante pour la sécurité des applications web. Des sites web majeurs comme Orkut, Youtube, Yahoo Mail, eBay, Amazon, Twitter et Facebook ont été confrontés à des attaques XSS au fil des ans.

3 principaux types d'attaques XSS avec exemples

Les attaques XSS sont généralement classées en trois grandes catégories :

• Attaques de cross-site scripting stockées (persistantes)
• Attaques de cross-site scripting réfléchies (non persistantes)
• Attaques XSS basées sur le modèle d'objet de document (DOM)

1. Attaques XSS stockées (persistantes)

Le cross-site scripting stocké ou persistant se produit lorsqu'un script malveillant est stocké de manière permanente sur le serveur de l'application web ciblée et présenté aux utilisateurs qui accèdent à une page spécifique. Cela se produit généralement lorsque la saisie utilisateur n'est pas correctement validée et désinfectée avant le stockage.

Le script nuisible est exécuté automatiquement lorsque d'autres utilisateurs chargent la page injectée. Étant donné que la charge utile est stockée par le serveur web puis intégrée dans une page HTML fournie à l'utilisateur, cela s'appelle une attaque XSS stockée.

L'exemple le plus courant d'attaque XSS stockée est les codes HTML non désinfectés qui sont postés comme messages sur des forums en ligne, des journaux de visiteurs ou des champs de commentaires. Tout utilisateur qui clique sur la page où le commentaire apparaît est affecté par l'attaque, sans même faire défiler jusqu'à la section des commentaires ou cliquer dessus.

2. Attaques XSS réfléchies (non persistantes)

Les développeurs d'applications doivent souvent se méfier de celles-ci. Dans une attaque XSS réfléchie, un utilisateur fournit une saisie à une application, puis l'attaque non persistante fait en sorte que les scripts côté serveur utilisent ces données immédiatement. Les scripts utilisent ces informations pour afficher une page web à l'utilisateur, mais la saisie n'a pas été correctement désinfectée.

On l'appelle une attaque de cross-site scripting réfléchie car le serveur renvoie immédiatement la charge utile malveillante en réponse à une requête HTTP de la victime non informée.

Par exemple, une application web de confiance appelée mybank.com a une fonction de recherche. Elle affiche la requête de recherche des utilisateurs sur la page de résultats sans validation et encodage de sortie appropriés. Un attaquant pourrait construire l'URL malveillante suivante pour exploiter cette vulnérabilité :

L'attaquant livrera ensuite cette URL légitime à des utilisateurs via des e-mails ou d'autres sites web neutres. Pensant qu'elle provient de leur site bancaire, l'un des utilisateurs clique sur le lien conçu, et le script du pirate est exécuté, et la victime n'en est pas plus sage. 

3. Attaques XSS basées sur le DOM

Les attaques XSS basées sur le DOM ont été définies pour la première fois par le chercheur en sécurité des applications web Amit Klein en 2005. Le mode objet de document est la représentation orientée objet d'une page web qui prend en charge le contenu dynamique. Les attaques XSS basées sur le DOM se produisent lorsque les pirates profitent des vulnérabilités du DOM. La page web ne change pas, mais le code côté client avec la charge utile corrompue sur le DOM s'exécute dans le navigateur de l'utilisateur.

Les attaques XSS basées sur le DOM se déroulent entièrement côté client, contrairement aux attaques XSS stockées et réfléchies, qui se produisent en raison de points faibles côté serveur.

Autres types d'attaques XSS

Outre les trois grandes catégories d'attaques XSS mentionnées ci-dessus, plusieurs autres variations d'attaques XSS exploitent des vulnérabilités spécifiques.

Self-XSS

Le self-cross-site scripting est plus une attaque d'ingénierie sociale où l'intrus trompe l'utilisateur pour qu'il colle un mauvais JavaScript dans son propre navigateur par lui-même. Ils attirent généralement les victimes en postant un message disant que l'utilisateur pourra recevoir une récompense en copiant et exécutant un certain code. En réalité, le code permet à l'attaquant de prendre le contrôle du compte de la victime.

Mutation XSS

Les attaques XSS par mutation ou mXSS sont rendues possibles en raison d'une vulnérabilité dans la propriété DOM appelée innerHTML et la façon dont le code HTML est analysé lors de la livraison de contenu dynamique. Les pirates injectent des codes malveillants spécialement conçus qui semblent sûrs, mais mutent et deviennent des vecteurs d'attaque XSS dans le navigateur.

XSS aveugle

Une variante des attaques XSS persistantes, les attaques de cross-site scripting aveugles entraînent le stockage de charges utiles malveillantes dans un serveur d'application web uniquement pour être exécutées par l'utilisateur backend ou l'administrateur de l'application.

7 mesures préventives contre les attaques XSS

Les vulnérabilités continuent d'exister dans bon nombre de nos applications web, mais les chercheurs ont proposé plusieurs solutions XSS, allant de l'analyse statique simple à des mécanismes de protection en temps réel complexes. Quelques-unes d'entre elles sont discutées ici.

1. Cadres web et bibliothèques de codage sécurisées

Les cadres web modernes et les bibliothèques de codage sécurisées fournissent un moyen standard de développer et de déployer des applications web sur internet sans défauts de conception et d'implémentation liés à la sécurité. Un développeur pourrait ne pas avoir toutes les ressources pour mettre en œuvre correctement les fonctionnalités de sécurité lors de la création d'une application à partir de zéro. Travailler avec des bibliothèques de codage sécurisées et des outils de cadre web aide à éviter les lacunes ou erreurs de sécurité dans le code.

2. Validation des saisies et encodage des sorties

La validation des saisies et l'encodage des sorties sont des techniques de défense clés contre les attaques XSS. La validation des saisies garantit que le contenu généré par l'utilisateur est dans le format attendu et rejette ou neutralise toute donnée qui ne correspond pas aux critères.

L'encodage des sorties désinfecte tout caractère spécial dans la saisie utilisateur inconnue afin qu'ils soient interprétés comme du texte brut. Cela confirme que le navigateur web n'enregistre pas la saisie utilisateur comme balisage ou code JavaScript en aucune circonstance. Ces deux techniques préviennent les vulnérabilités de sécurité que XSS peut exploiter.

3. Désinfection HTML

Un certain nombre de développeurs d'applications web utilisent des éditeurs WYSIWYG (ce que vous voyez est ce que vous obtenez) pour créer du texte et du contenu vidéo pour leurs pages web en langage HTML. Dans ces cas, il devient important de désinfecter les codes HTML pour se protéger contre les attaques XSS.

La désinfection HTML permet les balises HTML de base comme <b>, <i>, <u>, <em>, et <strong>. En même temps, elle supprime les balises plus avancées comme <script>, <object>, <embed>, et <link> qui peuvent être utilisées pour injecter des codes malveillants.

La Fondation Open Source pour la Sécurité des Applications (OWASP), une communauté de sécurité de premier plan, recommande d'utiliser DOMPurify pour la désinfection HTML.

4. Sécurité des cookies

Étant donné que les attaques XSS et autres cyberattaques ciblent les cookies web, il est important de mettre en œuvre une sécurité appropriée des cookies. Vous pouvez le faire en utilisant des attributs de cookies comme le drapeau "sécurisé" et "HttpOnly" pour affirmer que les cookies sont transmis uniquement via une connexion sécurisée.

5. Politique de sécurité du contenu (CSP)

La CSP est une couche de défense supplémentaire pour les propriétaires de sites web contre les menaces cybernétiques comme le XSS et d'autres attaques comme le clickjacking et les attaques par injection de code. Elle définit et restreint les sources à partir desquelles les navigateurs web peuvent charger du contenu, comme des scripts, des feuilles de style ou des images, et les URL à partir desquelles il peut être chargé. La CSP empêche l'exécution de codes malveillants en spécifiant des sources de confiance et en bloquant ou limitant le contenu.

6. Tests de sécurité

Les tests de sécurité réguliers, y compris les analyses de vulnérabilité et les tests de pénétration, classifient et traitent les vulnérabilités XSS. Les revues de code manuelles, les scanners de vulnérabilité, et les outils de test de logiciels avec automatisation peuvent faire partie de votre routine pour détecter les faiblesses potentielles et mesurer l'efficacité des techniques préventives contre le XSS.

7. Pare-feu d'application web (WAF)

Les WAF sont les logiciels de cybersécurité les plus courants pour protéger les applications web contre les attaques XSS et les injections SQL. Ils surveillent et filtrent le trafic entrant et utilisent l'analyse pour bloquer toute requête anormale vers l'application et refuser l'injection de scripts malveillants.

Les logiciels de sécurité comme les plateformes de gestion unifiée des menaces (UTM) protègent également efficacement contre les attaques XSS en intégrant plusieurs fonctionnalités de sécurité.

Cross-site scripting : Questions fréquemment posées (FAQ)

1. Qu'est-ce que le cross-site scripting ?

Les attaques de cross-site scripting (XSS) exploitent les vulnérabilités de sécurité des applications web qui permettent aux pirates d'injecter des scripts malveillants dans les pages web. Ces scripts volent des informations sensibles, manipulent les interactions utilisateur ou livrent des logiciels malveillants.

2. Quel langage est utilisé dans les attaques de cross-site scripting ?

Tout langage de programmation côté client comme Javascript, HTML, VBScript ou Flash peut être utilisé pour écrire des codes malveillants dans les attaques de cross-site scripting. Mais Javascript et HTML sont les plus couramment utilisés pour les attaques XSS.

3. Quels sont les trois types d'attaques de cross-site scripting ?

Les trois principaux types de XSS sont le XSS stocké, le XSS réfléchi et le XSS basé sur le DOM. 

4. Quelle est la différence entre XSS et CSRF ?

XSS injecte et exécute des scripts malveillants sur le navigateur d'un utilisateur, tandis que CSRF se concentre sur l'exploitation de la confiance placée dans la session authentifiée d'un utilisateur pour effectuer des actions non autorisées en son nom.

5. Quelle est la différence entre XSS et l'injection SQL ?

Les attaques XSS ciblent les utilisateurs du site web. L'injection SQL se concentre sur les mécanismes de stockage et de récupération des données du site web.

Défendre le domaine numérique

Aujourd'hui, le monde fonctionne sur des applications. Le cross-site scripting reste une vulnérabilité de sécurité dangereuse. Il expose les utilisateurs web à l'accès à distance, au vol de données et aux pertes monétaires. Mais avec une prise de conscience et des mesures préventives appropriées, son impact peut être atténué si vous pouvez aider à écrire un web plus sûr si vous mettez en œuvre les mesures préventives partagées ici.

Vous voulez écrire des codes plus sécurisés ? Découvrez les logiciels de formation au code sécurisé et comment ils aident les développeurs et les programmeurs.