Bonjour à tous. Dans cette deuxième vidéo, nous allons voir deux types de vulnérabilités XSS, qui sont les vulnérabilités XSS réfléchies ou encore non permanentes, et les XSS stockées ou dites permanentes. Commençons par les vulnérabilités réfléchies ou non permanentes. Les XSS réfléchies sont les vulnérabilités XSS les plus communes. Ce sont des vulnérabilités non stockées et qui dépendent de données entrées par l'utilisateur, par manque de contrôle côté serveur, qui va les utiliser telles quelles pour produire une page résultat. L'exemple le plus courant est celui du champ de recherche. En effet, lorsqu'un utilisateur entre un mot-clé à rechercher, ce mot-clé va être affiché sur la page résultat. Voyons une démonstration. Voici le fonctionnement normal. Un utilisateur entre le terme à rechercher et la page affiche les résultats s'il y en a, tout en rappelant la recherche. Comme vous pouvez le voir, lorsque je rentre un mot-clé, que celui-ci retourne des résultats ou non, il est affiché sur la page de résultats. Maintenant, testons une chose très simple. Mettons des balises HTML pour mettre le texte saisi en gras. Comme vous pouvez le constater, cela fonctionne. Maintenant, injectons un peu de JavaScript dans le but de faire un alert, c'est-à -dire ouvrir un popup alert contenant le mot test. Le popup s'ouvre après validation. En effet, le code JavaScript a été envoyé au serveur et celui-ci le retourne pour qu'il soit affiché côté client. Cependant, le navigateur, voyant que c'est du JavaScript, va l'interpréter. Essayons quelque chose de plus compliqué. Entrons le code JavaScript suivant. On ouvre notre JavaScript avec une balise script, windows.alert(document.cookie) et on ferme notre JavaScript avec une balise script fermante. Ce code doit retourner un cookie. Nous voyons que cela fonctionne. Le cookie est bien retourné par notre code JavaScript interprété côté navigateur. Pourquoi ces injections fonctionnent? Regardons notre code. Comme on peut le voir, il n'y a aucune vérification avant d'utiliser, c'est-à -dire envoyer et lire le code. Donc, le code JavaScript, HTML ou n'importe quel code interprété le sort. Ici, nous parlons de XSS non permanente. Cela signifie qu'elles ne sont pas stockées. La question est : comment cela peut nous être utile, car elle ne s'exécute que sur notre poste et non sur un poste cible? Pour qu'elle soit utile, il faut l'envoyer à un utilisateur, par exemple dans un mail. Considérons le scénario suivant. Un pirate informatique trouve une vulnérabilité non permanente sur un site Internet. Il envoie un mail à une victime lui demandant de cliquer sur un lien de la forme site_non_protege.fr/, recherche = mon_code_malveillant. Le code malveillant, s'il est bien fait, enverra les informations directement au pirate informatique. Celui-ci peut être document.location et entre parenthèses, http://site_malveillant.com/login.php. Que se passe-t-il? Quand une victime cliquera sur le lien, le site de l'attaquant sera appelé. La page login.php sera exécutée et l'utilisateur redirigé sera invité à rentrer son mot de passe. S'il le fait, alors le pirate aura le login et le mot de passe de la victime. Il est aussi possible de voler des cookies en procédant de la même manière. On pourrait penser qu'une victime ne cliquerait pas sur un lien si celui-ci est aussi lisible, c'est-à -dire que les balises script soient lisibles, que l'on peut voir le document.location. Mais il est possible de mettre le code en hexadécimal pour cacher le code JavaScript. Ici, le script <script> alert("XSS"), fermez la balise script, on va l'utiliser, mais écrit en hexadécimal. Cela donne le code suivant. [AUDIO_VIDE] [AUDIO_VIDE] Le code des XSS permanentes est un code injecté, stocké côté serveur. Prenons l'exemple d'un forum. Lorsque vous postez un message dans le forum, vous pouvez injecter du code JavaScript si le texte entré n'est pas vérifié. Par exemple, le code alert bonjour à tous sera exécuté à chaque fois que le message du forum sera affiché. Sauf qu'au lieu d'afficher du texte, un popup sera affiché avec le texte bonjour à tous. C'est ce type d'attaque que MySpace a subi en 2005. Samy Kamkar, un chercheur en sécurité, a répandu un ver sur MySpace. Un ver informatique est un programme qui s'auto-réplique. Ce ver était inoffensif. Il postait un message but most of all, Samy is my hero, et ajoutait Samy Kamkar en ami. Une personne visitant un profil compromis était infectée à son tour. Il a infecté plus d'un million de personnes en 20 heures. Une XSS permanente est plus critique qu'une XSS non permanente, car elle touchera chaque personne visitant la page web compromise. Voyons un exemple sur un forum que nous avons développé. Ce forum demande à un utilisateur de s'authentifier et sur la page d'authentification, qui est aussi la page d'accueil, les derniers commentaires sont affichés. Une fois authentifié, l'utilisateur peut poster des commentaires. Considérons ici qu'un pirate informatique décide d'injecter du code JavaScript. Pour l'exemple, un simple alert("hacked"). Vu que les derniers commentaires sont affichés, alors le code JavaScript stocké dans la base de données sera exécuté par les navigateurs de tous les utilisateurs allant sur le forum lorsque le commentaire du pirate sera parmi les derniers saisis sur celui-ci. Comme nous pouvons le voir, notre popup s'affiche. Et nous pourrions faire plus sophistiqué et plus utile comme avec les vulnérabilités non permanentes. [AUDIO_VIDE] Ici, nous montrons un exemple avec un simple popup qui s'affiche. Mais si les entrées utilisateurs ne sont pas vérifiées, un pirate peut faire plus dévastateur tel que le vol de cookie de session, le vol de mot de passe, la redirection d'un utilisateur vers un site appartenant au pirate. Vous connaissez maintenant les bases des vulnérabilités XSS. Nous avons vu des vulnérabilités XSS simples, mais d'autres plus complexes sont possibles. Il faut retenir et j'insiste là -dessus, qu'il est impératif de contrôler toutes les entrées des utilisateurs et de ne jamais leur faire confiance. Du moment qu'il y a un champ de saisie, un champ de recherche, qu'il y a la possibilité de poster des commentaires, une vulnérabilité est possible. Nous allons voir dans la prochaine vidéo comment se protéger.
