De façon générique, le "Cross-site scripting" correspond à l'action d'insérer des tags HTML dans une page dynamique générée par un serveur Web tiers (à l'insu de ce serveur).

Premier cas d'attaque

A moins que vous ne connaissiez déjà parfaitement ce problème, cette définition générique devrait vous laisser perplexe. Aussi allons-nous l'illustrer d'abord dans sa forme la plus simple : l'attaque (par " cross-site scripting ") au moyen d'un forum de discussion Web.

Un grand nombre de sites Web propose aujourd'hui des forums de discussion, dans lesquels les internautes dialoguent sur un sujet donné : chaque internaute peut poster sur le forum des messages qui sont ensuite consultables par tous les visiteurs du forum. Un participant indélicat peut cependant parfois poster une contribution apparemment anodine, mais qui contient en fait du code HTML malicieux (par exemple du code JavaScript). Lorsque ce message est ultérieurement consulté par un autre internaute, le code malicieux s'exécute alors sur le poste de cet internaute.

Il s'agit de l'exemple typique du " Cross-site scripting " : l'attaquant envoie des scripts offensifs sur le poste d'un utilisateur victime, en utilisant la complicité involontaire d'un site Web tiers. L'intérêt immédiat de cette attaque par rebond est que, contrairement au cas d'une attaque directe (cas où l'internaute victime visiterait un site pirate offensif), le site visité par la victime est à priori anodin, et elle n'a donc pas de raison particulière d'être méfiante.

Cette forme d'attaque (attaque via un forum web) est heureusement largement connue par les concepteurs de ces forums, et la grande majorité protègent les visiteurs en filtrant les messages postés (suppression des tags potentiellement dangereux).

Attaque plus sophistiquée

Le filtrage des données envoyées par un utilisateur vers d'autres utilisateurs est une mesure de protection évidente pour la grande majorité des concepteurs de sites Web. Cependant, il existe aussi d'autres formes du " Cross-site scripting " auxquelles les concepteurs de sites ne pensent pas forcément.

Supposons par exemple qu'un site commercial retourne, en cas de requête Web invalide, un message du type "la page xxx que vous demandez n'existe pas". Un pirate peut alors construire sur son propre site un lien qui, lorsqu'il est activé par un visiteur, envoie une requête invalide vers le site commercial et inclut dans cette requête un script. Lorsque le message d'erreur est finalement renvoyé vers l'utilisateur victime, ce script pirate s'exécute sur le poste de l'utilisateur. Cette fois, il n'est pas évident que les concepteurs du site aient pensé à filtrer les données incluses dans le message d'erreur, et l'attaque fonctionne. On notera cependant que, dans ce cas, l'attaque nécessite que la victime visite le site du pirate ou recoive un email HTML malicieux.

Cette forme d'attaque a plusieurs intérêts. Elle est tout d'abord relativement discrète (combien de fois êtes-vous arrivés sur une page du type " File not found " en suivant un lien hypertexte ?). Elle a aussi surtout l'intérêt (pour le pirate) de s'exécuter dans le contexte d'une communication entre l'utilisateur et le site web commercial : le script pirate retourné dans la page d'erreur par le site commercial bénéficie alors de tous les privilèges de cette communication. Il peut par exemple :

• lire les cookies créés par ce site commercial sur le poste l'utilisateur (éventuellement ces cookies peuvent contenir le compte et le mot de passe de l'utilisateur pour le site commercial),

• accéder au site commercial en se faisant passer pour l'utilisateur victime (pour effectuer des actions en son nom, ou pour bénéficier du droit d'accès de l'utilisateur alors que lui-même n'avait pas d'autorisation d'accès directe),

• contourner les mécanismes de sécurité du navigateur, dans le cas particulier où le site de rebond bénéficie de privilèges plus élevés qu'un site Internet ordinaire (cf. la notion de zone de sécurité de Internet Explorer, pour laquelle les actions autorisées à un site de confiance - par exemple un site Intranet - sont bien plus larges que celles autorisées aux autres).

De façon plus générale (mais cela n'est pas spécifique au cas du Cross-site scripting ") l'exécution d'un script malicieux sur le poste client peut avoir des conséquences impressionnantes. Il peut ainsi :

• rebondir sur le poste utilisateur pour accéder à des serveurs Web internes à l'entreprise.

• ou même modifier la configuration du poste utilisateur. Par exemple, dans le cas tout à fait particulier d'un poste vulnérable à la faille sur un contrôle ActiveX sous Outlook (CERT-IST/AV-2001.179), il pourrait être possible au pirate d'agir sur ce client de messagerie (par exemple pour mettre le pirate en copie de tous les messages ultérieurement envoyés ?).

Protections

Le " cross-site scripting " n'est pas un problème relatif à un produit particulier (serveur ou navigateur Web). Il s'agit d'un problème générique, qui est possible dès qu'un serveur Web :

• effectue de la génération dynamique de page,

• et ne vérifie pas systématiquement que les données qu'il reçoit et utilise ne sont pas nocives (pour lui ou pour l'internaute auquel il va envoyer des pages Web).

Même si ce problème est connu publiquement depuis début 2000, il reste d'actualité. Ainsi, il y a eu ce mois-ci deux avis Cert-IST relatifs à ce problème : CERT-IST/AV-2001.204 et CERT-IST/AV-2001.201.

L'effort de protection doit avant tout être porté au niveau de la conception des sites Web, en pratiquant une programmation défensive (validation et filtrage systématique de toutes les données reçues de l'extérieur, même les plus anodines), et en appliquant sur ces serveurs les correctifs de sécurité publiés par les constructeurs.

De façon complémentaire, les utilisateurs/administrateurs doivent être conscients des dangers liés à la navigation sur le Web, et agir en conséquence :

• configurer les navigateurs pour interdire l'exécution de scripts (ce qui est malheureusement de plus en plus difficile, puisque de nombreux sites deviennent ainsi inexploitables),

• ne pas visiter des sites " suspects ", susceptibles d'avoir un comportement agressif vis-à-vis de l'utilisateur,

• limiter l'utilisation des mécanismes de connexion automatique (par exemple au travers de cookies ou de fonctionnalités clientes spécifiques) pour les sites sensibles sur lesquels l'utilisateur a des accès.

Informations complémentaires

• Avis CA-2000-02 du CERT-CC : http://www.cert.org/advisories/CA-2000-02.html
• Article Microsoft sur le CSS : http://www.microsoft.com/Technet/itsolutions/security/topics/csoverv.asp