Comment est exploitée une faille XSS

Je vais inclure ce tuto dans les articles du site au courant de la semaine et essayer d'en composer sur une base régulière. Ça fait longtemps que j'y pensais, alors le voici en exclusivité sur PN.

Premièrement, le nom XSS vient de l’acronyme 'Cross Site Scripting' et non CSS qui peut porter à confusion avec 'Cascading Style Sheet' qui se trouve à être quelque chose de complètement différent.

Dans ce tuto, je vais vous expliquer comment une exploitation de cette faille peut être réalisée par une personne malveillante pour lui permette de recevoir par email le cookie du webmaster.

Comment reconnaître une faille XSS et comment elle se produit.
On analyse l’URL 'Uniform Resource Locator' (Adresse internet) qui peut nous donner plusieurs informations sur la façon dont les variables sont passées de page en page. Pour quelqu'un qui connaît beaucoup le codage web, c’est une très bonne façon d’imaginer comment la page est codée.

Voici un exemple d’URL qui pourrait être vulnérable.

Vous avez sûrement déjà remarqué des adresses longues d’un mètre, pleines d’information… Dans ce cas si, remarquez l’expression (var=pseudo). Mais qu'est-ce que ça veut dire? Simplement que la variable ici appelée (var) va porter la valeur (pseudo). Pour récupérer cette variable, le webmaster utilise ($_GET[var]). L’erreur qui provoque la faille XSS est que si cette variable est directement affichée dans la page sans être filtrée, on peut l’utiliser pour passer du code JavaScript directement dans la page. Pour savoir si une variable est vulnérable, il faut d’abord la tester. La façon la plus simple, c’est de générer une alerte javascript.


Si vous voyez une boite d’alerte s’ouvrir, c’est que le site est vulnérable.*

Comment exploiter la faille XSS
Maintenant que nous savons que le site en question ne filtre pas les caractères de programmation avant d'inclure la variable dans sa page, nous pouvons en profiter pour passer aux choses sérieuses. Puisque les caractères passés dans l’URL sont limités en nombres, nous devrons procéder à l’inclusion d’une page .js afin de pouvoir inclure tout notre codage sans limitation.

Voici donc à quoi cela ressemblerait.
(Petite remarque, la chaîne %20 est simplement un espace encodé. Nous en reparlerons plus tard)

C’est ici que la plus part des tuto arrête. Mais aujourd’hui, nous allons pousser le sujet plus loin et se rendre jusqu’à l’exploitation complète de la faille.

Afin de pouvoir recevoir le cookie par courriel, nous devons réussir à fabriquer un codage qui va ouvrir une page de façon parallèle et qui contient comme variable le cookie en question.

Dans le fichier cookie.js, nous allons ouvrire un IFRAME qui inclura en variable le cookie de la personne. Voici le codage.


Ce codage va envoyer à cookie.php la variable (cookie) qui elle contient la valeur du cookie de la personne qui va cliquer sur le lien. Il nous reste simplement à créé le codage qui va récupérer tout ça et nous l’envoyer par email.

Dans le fichier cookie.php, le code va ressembler à ceci.

Bien entendu, vous pouvez en profiter pour vous envoyer quelques informations supplémentaires sur la personne comme sont adresse IP qui peut toujours servirent pour d'autres sortes d'attaque.

Maintenant que nous avons tout mis en place, il ne vous reste plus qu'a utiliser un peut de SE (Social Engineering) Afin de demander au webmaster de bien gentiment cliquer sur le lien trafiqué. Pour cacher un peut le code malicieux, vous prouvez utiliser un encodeur URL. Le résultat ressemblerait à ceci :


Ceci peut également déjouer certain système de filtration et c'est un peu moins évident à deviner ... quoi que toujours un peut visible ...

Pousser plus loin...
Il existe énormément de place différente ou les failles XSS peuvent se produire. Plus récemment, plusieurs CMS se sont trouvés vulnérables au niveau des avatars et des inclusions d'images dans les messages en utilisant la balise IMG comme couverture.


Ou simplement fermer la balise IMG et poursuivre avec le code JS

Ce qui donnerait dans la source HTML

Ce protégé
Désormais, ayant vu l'exploitation qui peut en être faite, voici la sécurisation de cette faille :

Utiliser de façon systématique la fonction htmlspecialchars ou htmlentities sur les données non sûres (venant des users) avant leur AFFICHAGE, et seulement l'affichage, pas le stockage. (qui lui est inutile).

Soyez intelligent et restez WhiteHat!
Par CyberSee