Qu'est-ce que le Cross-Site Scripting (XSS) ?

Le Cross-Site Scripting (XSS) est un type de faille très répandu qui permet à un attaquant d'insérer du code malveillant (JavaScript) dans votre navigateur à l'aide d'une application Web vulnérable. L'attaquant peut diffuser son code malveillant de plusieurs façons. Il peut vous inciter à cliquer sur un lien (faille XSS réfléchie), ou attendre que vous visitiez une page sur laquelle le code malveillant a déjà été inséré (faille XSS stockée ou persistante).

Mais quelle est cette fenêtre contextuelle (ou « pop-up ») agaçante avec le numéro 1 ? Il s'agit simplement d'une manière dont certains peuvent prouver visuellement que leur Javascript (XSS) a été exécuté. Mais ne vous laissez pas avoir par cette fenêtre contextuelle : XSS représente bien plus que cela !

Que peuvent faire les pirates informatiques (« hackers ») avec XSS ?

Un hacker peut être en mesure de voler vos « cookies » et de se connecter à l'application comme s'il était vous !

Il peut être en mesure de vous rediriger vers un site Web malveillant à votre insu, dans le but de vous faire divulguer des informations sensibles, comme vos coordonnées bancaires.

Il peut ajouter des fausses pages de connexion à l'application vulnérable pour vous faire révéler votre nom d'utilisateur et votre mot de passe, qui lui sont ainsi communiqués.

Il peut même utiliser XSS afin de passer outre d'autres mesures de sécurité qui sont intégrées dans l'application et dans votre navigateur dans le but de vous protéger.

Les possibilités sont presque infinies. Prendre le contrôle de votre webcam ? Eh oui ! Écouter le son du micro de votre ordinateur ? Bien sûr !

Pour des attaques avancées, reportez-vous au Framework d'exploitation des navigateurs (Browser Exploitation Framework, BeEF).

Qui a été piraté par XSS ?

Les serveurs de la fondation Apache (créateurs et responsables de l'un des logiciels de serveurs Web les plus populaires sur Internet) ont été piratés dans le cadre d'une attaque qui a commencé avec XSS.

Une attaque XSS sur le forum officiel d'Ubuntu, un système d'exploitation Linux populaire, a permis aux attaquants de télécharger les noms d'utilisateurs, adresses e-mail et mots de passe de 1,82 millions d'utilisateurs.

Les attaques XSS ciblent généralement les utilisateurs de l'application ainsi que leurs réseaux locaux ; cependant, comme on l'a vu dans les exemples ci-dessus, lorsque ces utilisateurs sont des administrateurs, les serveurs Web de l'application sont également en danger.

Des failles XSS sont découvertes quotidiennement dans Facebook, Yahoo, Google, Twitter et d'autres sites Web très visibles par des chercheurs en sécurité indépendants qui participent à des programmes de récompenses pour la découverte de vulnérabilités (« bug bounties »).

Vous trouverez ici une liste d'autres attaques qui utilisent XSS - https://www.google.com/fusiontables/DataSource?snapid=S1158702BBoV

Que puis-je faire pour me protéger contre XSS ?

Assurez-vous que votre navigateur est tenu à jour et que toutes les fonctionnalités de sécurité y sont activées, comme le filtrage de Cross-Site Scripting (XSS). Si votre navigateur ne dispose pas d'un filtre XSS, comme Firefox, vous pouvez télécharger un complément qui vous permet de vous protéger contre XSS appelé NoScript.

Soyez vigilant lorsque vous cliquez sur un lien. Un lien peut sembler inoffensif, mais il peut contenir des codes XSS malveillants.

Lorsque vous quittez un site Web, pensez à vous déconnectez, cela rend la tâche plus difficile aux hackers qui tentent de voler vos « cookies ».

La partie technique ! Que puis-je faire pour protéger mon application Web contre XSS ?

Le Cross-Site Scripting se produit lorsque des informations issues de sources non fiables sont insérées sur une page sans avoir été préalablement filtrées et/ou encodées correctement.

Par exemple, si un utilisateur fournit son nom d’utilisateur pour se connecter et que l'application affiche ensuite ce nom d’utilisateur sans filtrage et/ou encodage... que se passe-t-il si le nom d’utilisateur contient des caractères HTML ? Le navigateur ne sera pas en mesure de faire la différence entre le nom d’utilisateur et le code HTML valide de la page. Les données (le nom d’utilisateur) sont mélangées au code (le HTML) ! Cela pourrait permettre à un utilisateur de se connecter avec un nom d’utilisateur contenant du code JavaScript malveillant et de le faire exécuter dans le navigateur dans le contexte de votre application Web.

Assurez-vous de filtrer le nom d'utilisateur avant de l'utiliser, par exemple, si les utilisateurs doivent avoir des noms d'utilisateurs composés uniquement de caractères alphanumériques, veillez à ce que cela soit appliqué en filtrant les entrées. Ayez recours à une liste blanche ! Comparez le nom d'utilisateur aux « bons caractères connus » plutôt qu'aux « mauvais caractères connus ».

Utilisez le bon codage ! S'il est prévu que le nom d'utilisateur soit affiché en code HTML, assurez-vous d'encoder tous les caractères du nom d'utilisateur pour HTML. Ainsi, le navigateur saura ce qui est censé être présenté en HTML et ce qui ne l'est pas. Mais ce n'est pas qu'une question de codage HTML ! Vous devez encoder pour le bon « contexte » de sortie. Reportez-vous aux liens ci-dessous pour de plus amples informations.

Scannez vos applications afin de détecter les failles XSS potentielles. Il existe de nombreux scanners de sécurité Web automatisés qui détectent XSS dans des applications Web. Vous pourriez essayer OWASP ZAP, qui est un programme open source.

Paramétrez les cookies de votre session en activant la fonctionnalité HttpOnly. Cela indique au navigateur que JavaScript ne peut avoir accès au cookie, ce qui protège ainsi vos utilisateurs contre le vol de leurs sessions.

Un en-tête HTPP appelé Content Security Policy (CSP) peut être envoyé par le serveur Web pour indiquer au navigateur le code JavaScript qu'il peut exécuter, et à partir d'où. Il utilise une liste blanche !

Enfin, pourquoi ne pas installer un Firewall d'applications Web (Web Application Firewall, WAF) comme mod_security qui est un projet de codage open source ! Un WAF confère à votre application une couche de défense supplémentaire contre les attaquants, mais il doit être employé dans le cadre d'une défense approfondie et non comme unique solution, puisqu'il existe des moyens de passer outre.

Où puis-je trouver de plus amples informations ?

Les deux types de failles XSS mentionnés sur cette page (faille réfléchie et stockée) ne sont pas les deux seuls ! Nous n'avons abordé qu'un seul aspect de la question. Vous souhaitez en savoir plus ?

Le projet Open Web Application Security Project (OWASP) est une excellente ressource pour tout ce qui se rapporte à la sécurité des applications Web. Jetez un œil à leur article wiki sur XSS ou à leur Guide de référence rapide pour la prévention de XSS. Pour obtenir des informations sur d'autres types de vulnérabilités d'applications Web, consultez OWASP Top 10.

Merci de nous avoir lus,
Ryan Dewhurst & Thomas MacKenzie

---

Cet article entend être simple, concis, précis, et rédigé en français clair.

Design de la page inspiré par http://justinjackson.ca/words.html

---

Thanks to Lagarde Languages for this translation. English version here.