Se protéger des failles de sécurité XSS/cross-site scripting

Le cross-site scripting (abrégé en XSS) est un type de faille de sécurité de sites Internet. Des scripts malveillants sont introduits (le terme « injecté » est habituellement utilisé) dans des sites Web, afin de pouvoir attaquer les systèmes des utilisateurs. Les scripts sont des programmes dans des langues de script (JavaScript par exemple), qui sont exécutés dans le navigateur d'Internet. Il existe des variantes inoffensives telles que les fenêtres pop-up. Dans le pire des cas, les attaquants (ou pirates) pourront se procurer des informations sensibles en utilisant ce script ou alors accéder aux ordinateurs des internautes dans le plus grand secret.   

Le danger potentiel du cross-site scripting est qu’il peut transférer les données des utilisateurs au navigateur sans vérification. C’est ainsi que des scripts malveillants peuvent atteindre les clients concernés. A partir de là, les applications peuvent manipuler les scripts côté serveur tels que les formulaires d’inscription des utilisateurs. Ce processus d’inscription semble fonctionner, l’internaute le considère comme anonyme et verrouille alors les données qui sont transférées sans filtre.

Le but de ces attaques exploitant une faille XSS n’est pas seulement de voler des données sensibles et de rendre vulnérable le client concerné. Ces scripts sont divers et variés. D’un côté, il y a ceux qui font passer les clients pour des pirates informatiques et qui utilisent les techniques de hameçonnage ainsi que des programmes malveillants. De l’autre côté, on compte ceux qui modifient des sites Internet pour les discréditer. Ces attaquants restent la plupart du temps anonymes.

Exemples de cross-site scripting

Voici une courte liste accompagnée d’explications sur les différentes sortes de cross-site scripting (XSS). 

cross-site scripting / XSS réfléchi

Un script malveillant est envoyé à un serveur Web via le chargement d’une adresse URL manipulée ou via l’envoi d’un formulaire préparé. Ce serveur Web retourne par la suite ce script au client sans vérification. Le code malveillant n’est pas enregistré sur le serveur et existe seulement de manière temporaire lors du chargement de la page Web via le client. Les cibles préférées de ces scripts sont les sites Internet généraux ou les logiciels de messagerie.

Exemple : le cyber agresseur dissimule son script dans un lien tout préparé. Par la suite, il essaye de le transférer (souvent par email). Le code malveillant se déclenche seulement si l’utilisateur clique sur le lien qu’il a reçu. S’il le fait, une page s’affichera, par exemple une imitation de la page d’accueil de sa banque en ligne. Au lieu d’envoyer les données au serveur Web de la banque, le script les transfère à l’adresse que le pirate a déterminée auparavant. 

cross-site scripting / XSS persistant

Les scripts malveillants sont enregistrés sur le serveur Web et livrés au client à chaque chargement. C’est pour cela que certaines applications Web en particulier sont plus propices aux cyberattaques, car elles enregistrent les données des internautes côté serveur et les diffusent souvent sans codage. Les sites les plus visés par ces scripts sont les blogs et les forums.  

Exemple : Dans un forum, les posts des utilisateurs sont enregistrés dans une base de données, souvent sans vérification. Les attaquants saisissent cette opportunité pour ajouter des posts comportant des scripts malveillants. Par la suite, les utilisateurs insouciants reçoivent ce lien par email ou alors arrivent par hasard sur le post en question et cliquent dessus.

Cross-site scripting / XSS basé sur le DOM

Ce type d’attaque est aussi appelé XXS local. En chargeant une de ces adresses URL manipulées, un code malicieux est exécuté sans vérification grâce à une faille présente dans un script côté client. Au contraire des XXS persistants et réfléchis, le serveur Web n’a ici pas sa place dans le processus. Cette variante de script porte également atteinte aux sites Web statiques, qui prennent ce langage de script en charge.

Exemple : le script basé sur le DOM fonctionne comme les cross-site-scriptings réfléchis : l’utilisateur ouvre un lien. Après avoir cliqué dessus, un script lit la valeur d’argument de l’URL et exécute le code de script qu’il contient. C’est ainsi que les cookies de session par exemple sont volés.

Comment se protéger des attaques XSS

Les utilisateurs et les administrateurs de sites ne peuvent sous-estimer les conséquences néfastes que le cross-site scripting peut avoir. D’un côté, les utilisateurs risquent de perdre leurs données et servent de complices aux attaquants. De l’autre côté, les administrateurs de sites sont responsables des données de leurs clients / visiteurs et sont donc également concernés par ces attaques. Les contenus malveillants ainsi que les pannes de serveurs diminuent le nombre de visites, ce qui peut à long terme avoir un impact négatif sur le classement dans les moteurs de recherches. Par ailleurs, la relation de confiance entre l’utilisateur et le site Internet est compromise ce qui peut également mener à des pertes financières. En tant qu’administrateur de site Web mais aussi en tant qu’utilisateur, il convient de prendre des mesures pour prévenir ces failles de sécurité de type cross-site scripting.

Mesures de prévention pour les internautes

La meilleure des façons pour prévenir un cross-site scripting côté client est de désactiver le support de JavaScript dans votre navigateur. En faisant cela, les XSS basés sur le DOM qui visent JavaScript n’ont aucun effet, étant donné que l’application malicieuse n’est pas démarrée. Pour certains navigateurs, il existe des modules qui permettent de prévenir ces attaques XXS. Firefox par exemple dispose de l’extension NoScript. Par défaut, tous les contenus actifs des sites Internet tels que JavaScripts, Java-Applets, Adobe Flash ou Microsoft Silverlight y sont automatiquement bloqués. Il est possible de lever ce blocage temporairement ou de les mettre en liste blanche si vous êtes sûr et certain de leur fiabilité. Malgré le danger que présente le cross-site scripting, il faut être sceptique à l’égard de  données externes telles que les liens et bien les vérifier avant de les utiliser.

Les mesures à prendre pour se protéger des attaques XSS

Pour protéger vos applications Web d’attaques XSS, il vous faut considérer que tous les éléments Internet ne sont pas sécurisés. Il faut les vérifier avant que le serveur Web ne puisse les recevoir. La méthode la plus sûre est de l’insérer sur une liste blanche (comme dans le module de navigateur NoScript). Le fait de scanner les ressources arrivant sur votre site Internet et d’autoriser l’accès seulement aux contenus fiables constitue un excellent moyen de protection contre le type de faille de sécurité cross-site scripting.

En plus de ces données entrantes, il faut penser à sécuriser les données sortantes. Il est pour cela nécessaire de remplacer les caractères spéciaux HTML qui posent problème par leurs référents. Ainsi, ces éléments sont interprétés comme normaux et les scripts malveillants ne peuvent démarrer.  La plupart des langages de programmation et de script tels que Perl, JavaScript ou PFP disposent de fonctions déjà prédéfinies pour substituer ou masquer ces caractères que vous utilisez sans le savoir. Vous pouvez également vous défendre contre ces attaques XSS aussi en utilisant des pare-feu.

Le cross-site scripting est souvent considéré comme une première étape dans les attaques plus graves, qui peuvent compromettre la protection complète des données entrantes et sortantes de votre serveur Web.

Cet article vous a-t-il été utile ?