CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Vulnérabilité de type
« Cross Site Scripting »
Gestion du document
Une gestion de version détaillée se trouve à la fin de ce document. 1 IntroductionUne vulnérabilité de type Cross Site Scripting, injection de code indirecte en français, est exploitable sur les serveurs web ou sur les applications web qui publient du texte fourni par le visiteur sans l'avoir filtré. Un utilisateur malintentionné peut, en utilisant cette vulnérabilité, insérer du code dans une page HTML renvoyée dynamiquement par le serveur. Ce code est généralement écrit dans un langage de script (par exemple JavaScript ou VBscript) qui est interprété par le navigateur de la victime.Le terme anglais Cross Site Scripting est abrégé en XSS car l'acronyme CSS est déjà utilisé dans le monde du web pour Cascading Style Sheet. 2 Historique et évolution du Cross Site ScriptingLes vulnérabilités de type Cross Site Scripting sont apparues lors de la généralisation de l'usage des langages de script dans les pages web. Ces vulnérabilités ont fait l'objet d'un premier communiqué officiel en février 2000 par le CERT/CC (voir section documentation).Depuis, leur exploitation s'est diversifiée et concerne toutes sortes de services (webmails, enchères en ligne, forums...). Beaucoup de logiciels ont été touchées par cette vulnérabilité dont les plus connus sont les serveurs web IIS et Apache, les serveurs d'applications IBM Websphere et Tomcat mais aussi les nombreux gestionnaires de contenus (CMS), de forum, les outils de statistiques (phpMyVisites, AwStats), le relais mandataire Squid... 3 Exemples de Cross Site Scripting3.1 Moteur de recherche d'un serveur webCet exemple est extrêmement fréquent.Dans ce cas, un serveur web propose un formulaire de recherche à ses visiteurs. Les mots-clefs entrés pour la recherche sont souvent renvoyés à l'internaute dans des messages de la forme (pour une recherche avec le mot CERTA) : 14 documents trouvés pour la recherche de CERTA.
Un site vulnérable à l'injection de code indirecte ne filtre pas les données entrées par le visiteur avant de les lui retourner. Donc l'insertion dans le formulaire de la chaîne de caractères : <script>alert('Ce serveur est vulnérable !')</script> retournera cette séquence JavaScript au navigateur de l'internaute qui l'interprètera en ouvrant une fenêtre avec le message : Ce serveur est vulnérable !
L'exploitation malveillante ne se contente évidemment pas de cet affichage bénin. Plus généralement, toute entrée par formulaire et toute variable présente dans une adresse réticulaire (URL) peuvent servir à une attaque par injection de code indirecte. 3.2 Génération automatique du message d'erreur d'un serveur webLorsqu'un serveur web génère un message d'erreur à partir de l'adresse réticulaire qu'il a reçue, sans avoir au préalable pris la précaution de l'analyser, il est également vulnérable à cette faille.
Prenons le cas d'un serveur ayant pour nom d'hôte www.exemple.tld, sur lequel l'internaute cherche la page xxx. Si ce serveur ne trouve pas la page demandée, il retourne une réponse du type : Erreur 404 : Page xxx non trouvée. Imaginons qu'un utilisateur malintentionné crée sur un site web (ou dans un courriel) une page HTML contenant le lien hypertexte suivant :
<a href="http://www.exemple.tld/<script>alert('Ce serveur est vulnérable !')
</script>''> Texte incitant le visiteur (ou le destinataire) à cliquer</a>}.
Le visiteur répondant à l'incitation envoye l'URL du champ href au serveur www.exemple.tld. Ce dernier cherchera alors le fichier <script>alert('Ce serveur est vulnérable !')</script> qu'il ne trouvera pas. Il renverra donc une réponse d'erreur 404 contenant le script (inoffensif dans ce cas) qui aura pour effet d'afficher une fenetre avec le texte : Ce serveur est vulnérable !
Cette vulnérabilité était présente sur le serveur web Microsoft IIS version 4.0 et version 5.0 (voir avis de sécurité CERTA-2000-AVI-035 du CERTA). 3.3 Vol d'un cookie par envoi d'un courrielUn serveur web est chargé d'afficher les courriels au format HTML contenus dans la boîte aux lettres d'un utilisateur (webmail). L'authentification de l'utilisateur est réalisée au moyen de cookies d'identification envoyés par le serveur web. Si le serveur est vulnérable, un utilisateur malintentionné peut, par le biais d'un courriel astucieusement écrit, récupérer le cookie d'identification envoyé par le serveur web. Le courriel envoyé par l'utilisateur malintentionné est de la forme : sujet : du texte anodin corps : du texte anodin <\textarea> <script>un script qui récupère le cookie d'identification</script> En lisant ce courriel à travers les pages créées par le serveur, la victime n'a pas connaissance du texte se trouvant après la balise <\textarea> qui est alors considéré comme du code HTML. L'emploi de la balise <script> permet l'exécution d'un code qui sera interprété par le navigateur. 3.4 Situations voisines du Cross Site Scripting, forums et blocs-notes (blogs)Les forums qui permettent la publication de messages contenant du HTML facilitent l'injection de code dans ce qui sera retourné à l'internaute visiteur.De même les commentaires ajoutés à des billets dans des blogs sont propices à ce type d'injection. L'interdiction du HTML ou le contrôle strict de celui-ci dans ces messages et ces commentaires réduisent les possibilités d'attaques. 4 Impacts du Cross Site ScriptingLes impacts de cette vulnérabilité sont liés au langage de script utilisé pour réaliser l'attaque par Cross Site Scripting, en particulier aux opérations qu'il permet et aux droits accordés à l'interpréteur de script.Si le langage JavaScript est utilisé, il est alors possible :
Les risques liés à cette vulnérabilité sont donc nombreux : déni de service de la machine victime, utilisation de la machine victime à des fins malveillantes, récupération de données personnelles. 5 Recommandations pour limiter le Cross Site Scripting5.1 Recommandation sur les serveursLa vulnérabilité est fondamentalement l'acceptation sans vérification de données fournies par l'internaute et leur renvoi tel quels.Pour contrer les attaques basées sur l'injection de code indirecte, il convient donc de filtrer ces données :
La surveillance des journaux de connexion et des journaux d'interrogation des bases de données (sites dynamiques) peut indiquer des tentatives et des réussites d'exploitation de ces vulnérabilités. 5.2 Recommandation sur les navigateursL'utilisateur ne peut corriger cette vulnérabilité du serveur, mais en restreindre la possibilité d'exploitation.Il est recommandé à l'internaute :
6 Documentation
Gestion détaillée du document
CERTA 2012-01-04 |
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
