En quoi consiste une attaque par XSS ?

Une attaque par XSS consiste à introduire un code malveillant dans des plateformes en ligne par ailleurs sûres. Ce type de menace résulte de l’injection de script malveillant par des cybercriminels dans le contenu du site internet visé, qui est par la suite enfermé dans le contenu dynamique recueilli par le navigateur de la proie. En fait, le navigateur n’est pas capable de distinguer les balises valides de celles du pirate informatique et son rôle se limite juste à les exécuter.

Ainsi, ces scripts malveillants ont accès aux cookies et aux données sensibles stockées par le navigateur ou encore aux jetons de session. Les hackers se servent également d’une attaque XSS pour répandre un malware, perturber les médias sociaux, réécrire le contenu du site et hameçonner les identifiants d’un internaute. À l’inverse des autres attaques en ligne, les failles Cross-site Scripting ne visent pas immédiatement le programme lui-même, mais principalement ses utilisateurs.

Le Cross-site Scripting consiste à utiliser une plateforme web fragile, pour qu’il révoque un script malveillant aux internautes. Habituellement, il privilégie le langage JavaScript, toutefois, il est possible d’utiliser tous les langages de programmation côté client. Les hackers visent des sites web dont les fonctions sont fragiles et qui donnent accès aux utilisateurs, à savoir les formulaires de connexion, les barres de recherche, les zones de commentaire, etc. Les cybercriminels injectent leur code malveillant au site web légal, escroquant ainsi les navigateurs pour que le malware s’active lors de chaque visite du site.

Comme le JavaScript s’exécute sur la page du navigateur de la cible, des renseignements sensibles sur l’internaute authentifié sont exposés au vol lors de la session, permettant ainsi aux hackers de viser les administrateurs de sites et d’exposer les sites Web.

En fonction de la manière dont le code a été injecté, le contenu malveillant peut très bien ne pas se trouver sur la page authentique, mais elle peut devenir un élément de transition qui est totalement exclu du site qu’une fois au moment de l’exploitation. Cela peut engendrer l’illusion que le site web original est compromis, ce qui n’est pas le cas.

Le Cross-site Scripting peut aussi être réalisé directement, par exemple, dans un message d’email. Dans certains cas, une attaque par XSS ne cible pas de victime spécifique. Le pirate exploite juste une faiblesse dans un programme ou un site et espère juste qu’un visiteur tombe dessus.

En fonction de la grandeur de la frappe, la faille XSS peut engendrer :

• la compromission des comptes utilisateurs ;
• l’activation des trojans ;
• la modification du page dans le but de duper les utilisateurs et les conduire à divulguer des renseignements confidentiels ;
• la révélation des cookies de session qui permet à un pirate d’usurper l’identité d’un utilisateur et d’exploiter leur compte personnel.

La réussite d’une attaque XSS peut engendrer des impacts dévastateurs pour la réputation d’une activité en ligne ou encore la relation avec les clients. Inopportunément, les failles à l’origine de ces attaques sont très répandues.

Les failles XSS exploitent les faiblesses dans plusieurs espaces de programmation, surtout JavaScript, Flash, VBScript et ActiveX. Elles visent particulièrement JavaScript, car ce langage peut être intégré de manière limitée dans tous les navigateurs. Cette tendance à exploiter les plateformes communément utilisées rend ces failles à la fois banales et dangereuses.

L’exploitation d’une attaque par XSS par un pirate peut engendrer les actions malveillantes suivantes :

• rediriger les internautes vers un site web malveillant ;
• enregistrer les attaques de l’utilisateur sur le clavier ;
• s’introduire dans l’historique de navigation de l’internaute ainsi que le contenu des presse-papiers ;
• réaliser des failles basées sur un navigateur web ;
• avoir les informations sur les cookies d’un internaute qui se connecte sur une plateforme ;
• voler le jeton de session de connexion qui permet au hacker d’interagir avec le programme comme une victime, et ce, sans savoir le mot de passe ;
• contraindre l’internaute à envoyer des demandes à un serveur, contrôlé par le pirate ;
• changer le contenu de la page ;
• piéger la cible afin qu’elle dévoile ses identifiants pour accéder au programme ;
• infecter la cible avec d’autres codes malveillants grâce à une faiblesse du navigateur web, voire contrôler l’appareil de la cible.

Selon leur objectif, les pirates ont la possibilité d’utiliser les scripts intersites de différentes façons : ‍

Scripts intersites sauvegardés (persistants)

Les attaques par XSS stockées se manifestent lorsqu’un pirate dépose leur charge utile dans un serveur affecté, ce qui conduit le site à propager un code malveillant aux autres internautes.

Il s’agit là du type de scripting intersite le plus dangereux et le plus utilisé, car cette technique ne demande pas une action initiale venant du hacker et qu’elle est capable de compromettre plusieurs internautes par la suite. Les champs de profil comme le nom d’utilisateur ou l’adresse électronique qui sont stockés sur le serveur et édités sur la page du compte sont des exemples de failles par script intersite stocké.

Scripts intersites réfléchis

Les failles XSS réfléchies se développent au moment où la charge utile est gardée dans les informations envoyées par le navigateur au serveur.

À titre d’exemple, un pirate peut déposer un script malveillant dans les renseignements envoyés par le formulaire de recherche ou de contact d’un site web. Un cas très courant de scripting intersite réfléchi est le formulaire de recherche dans lequel les internautes envoient leur demande au serveur, et ils sont les seuls à trouver le résultat.

Scripts intersites basés sur le DOM

Les attaques par XSS basées sur le DOM se constituent quand ce n’est pas le serveur en soi qui est vulnérable, mais le JavaScript de la page.

Comme le langage est utilisé pour donner plus d’interactivité à la page, les arguments dans l’URL peuvent être utilisés pour changer la page suite au chargement. En transformant le DOM quand il ne nettoie pas les valeurs qui proviennent de l’internaute, les pirates informatiques sont capables d’associer à la page un code malveillant.

Le cas d’une faille XSS basée sur le DOM est le moment où la plateforme web transforme le choix de la langue par défaut pour celle qui est offerte dans l’URL.

Installer et conserver la sensibilisation

Pour garantir la sécurité de votre application web, les personnes engagées dans sa conception doivent être conscientes des risques liés aux faiblesses XSS. Pour ce faire, former les différents acteurs reste la meilleure solution.

Ne jamais faire confiance à une entrée utilisateur

Pour se prémunir de ce genre d’attaque, il faut considérer que toutes les entrées utilisateurs sont non fiables. Chaque entrée utilisateur utilisée en tant que sortie HTML expose à une attaque XSS.

Faire usage de l’échappement ou codage

Il est judicieux d’utiliser une méthode d’échappement/de codage adaptée selon l’endroit où l’entrée de l’utilisateur doit être utilisée : échappement CSS, échappement HTML, échappement URL, échappement JavaScript.

Assainir le HTML

Si l’accès utilisateur doit avoir du HTML, vous ne pouvez pas l’échapper/le coder, puisque cela ne fera que détériorer les balises valides. Dans ce cas, privilégier une bibliothèque fiable et vérifiée capable d’analyser et de nettoyer le HTML. Sélectionnez la bibliothèque selon votre langage de développement : HtmlSanitizer pour .NET ou SanitizerHelper pour Ruby on Rails.

Réaliser des scans régulièrement

Les faiblesses XSS peuvent être pilotées par les développeurs ou par des bibliothèques/logiciels externes/modules. Il est recommandé de scanner fréquemment les applications web avec un scanner de vulnérabilité web.