Cross Site Scripting ... la suite

Dans un billet précédent, je vous ai expliqué les bases du Cross Site Scripting (XSS), en incluant un exemple d'une attaque stockée par le serveur (Rappelez vous : un outil de CRM acceptant du code HTML ou JavaScript dans les commentaires.
Voyons aujourd'hui une attaque XSS par injection de paramètres et nous verrons un exemple fictif de ce qu'on peut faire avec ce genre d'attaque sur un site vulnérable.

Je ne reviendrais pas sur la présentation de ce qu'est le XSS ici, si vous voulez vous en souvenir, je vous invite à lire le billet précédent sur ce genre d'attaque en cliquant ICI.
Nous avons vu qu'il est dangereux de laisser à un utilisateur de votre site la possibilité de saisir du code HTML ou JS, voyons maintenant une autre entrée possible : une attaque de type XSS par passage de paramètres.

Introduction :

Certaines applications web, bien que ne laissant pas à un utilisateur la possibilité de stocker son attaque XSS sur le serveur, sont vulnérables par injection de paramètres.
On se rend compte, que souvent, l'URL d'une application contient bien plus d'informations que la simple localisation de la ressource, comme par exemple des paramètres de session, c'est sur cette partie de l'URL qu'un attaquant va essayer d'agir, nous verrons tout à l'heure comment un attaquant peut accéder à vos comptes bancaire en ligne sans s'authentifier !
Cette vulnérabilité est facilement vérifiable en appelant une page (depuis votre navigateur favori) qui n'existe pas sur le serveur, avec du code HTML dans l'URL : par exemple www.une-banque-.fr/<B>blabla</B>
Si la page affichée en retour est :

You don't have permission to access /<B>blabla.html</B> on this server.

ou

The document /<B>blabla.html</B> does not exist on this server.

ou tout autre message contenant littéralement votre code HTML, alors le site n'est pas vulnérable. En revanche, si la page affichée ressemble à ça :

The document blabla.html does not exist on this server.

Alors il y a de forte chance que le site soit vulnérable à une attaque de type XSS.
Attention : Il est possible que ce test soit faux alors que le site est vulnérable par d'autre porte d'entrées, en effet, si le site ne semble pas vulnérable par cette méthode, il faut en essayer une autre : Forcer l'application a délivrer un message d'erreur afin de tester le script délivrant les erreurs.
Imaginons qu'après quelques essais, je trouve que les pages d'erreurs sont générées par une page en php err_msg.php, il nous faut alors tester la vulnérabilité sur cette page en appelant toujours le même paramètre : <B>blablabla</B>, ce qui donnera l'URL de test suivante : www.une-banque-.fr/err_msg.php?msg=<B>blablabla</B>
Si le mot blablabla apparaît en gras quelque part sur la page d'erreur, le site est vulnérable.

C'est vulnérable, mais qu'est ce qu'on peut en faire ? :

Simplement envoyer un email à un utilisateur,contenant un lien HTML, vers le site vulnérable sur la page d'authentification, en incluant un script qui récupérera les informations saisies ou les cookies de connexion, afin de tenter une attaque en rejouant le cookie d'authentification. (Hijacking par rejeu, ou sidejacking, ou selon le cookie vol de mot de passe
Notre exemple fictif se base sur un site bancaire vulnérable et l'attaque sera en XSS bien entendu, aboutissant sur un sidejacking...

Un exemple :

L'attaque va se dérouler en 7 étapes, comme sur le schéma si dessous.

Figure 1 : Attaque XSS par imposition d'un cookie.
Etape 1 : Le pirate va ouvrir la page d'authentification d'un serveur bancaire dans son navigateur, en retour le site bancaire va lui fournir un cookie de session.
Le pirate envoi une requête contenant les éléments suivants :
GET auth.jsp HTTP/1.0
host : www.banque.fr

Etape 2 : En retour le serveur inclut dans sa réponse l'élément suivant :
set-cookie : JSESSIONID=0987654321
Etape 3 : Le pirate va envoyer un email en HTML à sa victime, l'email contiendra un lien vers le site de la banque, formaté de la façon suivante :
<a href=http://www.banque.fr/erreur.jsp?msg=<script>document.cookie= "JSESSIONID=0987654321;domaine=.banque.fr"</script>
Etape 4 : La victime va se connecter sur le site de sa banque en ligne, en prétendant avoir le cookie de session imposé par le pirate ...
Etape 5 : La page d'erreur va exécuter le script dans le contexte du client et rediriger la victime vers la page d'authentification.
Etape 6 : La victime s'authentifie sur son site bancaire en utilisant le cookie de session imposé par le pirate. Sur le serveur, ce cookie de session est désormais validé en tant que client authentifié.
Etape 7 : Le pirate va recharger la page du site bancaire en utilisant le cookie de session fournit lors de la première connexion. Le cookie étant valide sur le serveur comme session authentifié, le pirate a désormais accès à vos comptes bancaire !

Comment se protéger (au niveau utilisateur):

La méthode de protection est simple : REFUSEZ les emails en HTML, et ne cliquez JAMAIS sur un lien reçu par email. Notez l'URL du lien et saisissez la manuellement dans la barre d'adresse de votre navigateur.
ATTENTION : L'exemple fournit ci-dessus est fictif, il est présenté dans un but pédagogique, je ne saurai être tenu pour responsable de quelques manière que ce soit si vous utilisez cette technique. Le piratage informatique est un acte illégale répréhensible par la loi.