Les attaques Cross-Site Scripting (XSS): définition et comment s’en prémunir ?

Les attaques Cross-Site Scripting (XSS): définition et comment s’en prémunir ?

Hossam M.
Calendar picto
28/2/2022
Clock picto
5 min

Les attaques de type Cross-Site Scripting (XSS) sont un type d'injection, dans lequel des scripts malveillants sont injectés dans des sites web par ailleurs bénins et de confiance. Les attaques XSS se produisent lorsqu'un attaquant utilise une application web pour envoyer un code malveillant, généralement sous la forme d'un script côté navigateur, à un autre utilisateur final. Les failles qui permettent à ces attaques de réussir sont assez répandues et se produisent partout où une application web utilise les entrées d'un utilisateur dans la sortie qu'elle génère sans les valider ou les coder.


Un attaquant peut utiliser XSS pour envoyer un script malveillant à un utilisateur sans méfiance. Le navigateur de l'utilisateur final n'a aucun moyen de savoir que le script n'est pas digne de confiance et l'exécute. Comme il pense que le script provient d'une source fiable, le script malveillant peut accéder à tous les cookies, jetons de session ou autres informations sensibles conservés par le navigateur et utilisés avec ce site. Ces scripts peuvent même réécrire le contenu de la page HTML.


Quels sont les types d'attaques de type Cross-Site Scripting ?

En fonction de leurs objectifs, les attaquants peuvent utiliser les scripts intersites de différentes manières. 


  1. Scripts intersites stockés (persistants)

Les attaques par cross-site scripting stockées se produisent lorsque les attaquants stockent leur charge utile sur un serveur compromis, amenant le site Web à diffuser un code malveillant aux autres visiteurs.


Comme cette méthode ne nécessite qu'une action initiale de la part de l'attaquant et qu'elle peut compromettre de nombreux visiteurs par la suite, il s'agit du type de scripting intersite le plus dangereux et le plus couramment utilisé. Les champs de profil tels que le nom d'utilisateur ou l'adresse électronique, qui sont enregistrés sur le serveur et affichés sur la page de votre compte, sont des exemples d'attaques par script intersite stockées.


  1. Scripts intersites réfléchis

Les attaques cross-site scripting réfléchies se produisent lorsque la charge utile est stockée dans les données envoyées par le navigateur au serveur.


Par exemple, un attaquant peut stocker un script malveillant dans les données envoyées par le formulaire de recherche ou de contact d'un site Web. Un exemple typique de scripting intersite réfléchi est un formulaire de recherche, où les visiteurs envoient leur requête de recherche au serveur, et seuls eux voient le résultat.


  1. Scripteur intersite autonome

L'auto-scripting intersite se produit lorsque les attaquants exploitent une vulnérabilité qui nécessite un contexte extrêmement spécifique et des modifications manuelles. La seule personne qui peut être victime est vous-même.


Ces modifications spécifiques peuvent inclure des éléments tels que les valeurs des cookies ou l'ajout de vos propres informations à une charge utile.


  1. Cross-Site Scripting aveugle

Les attaques cross-site scripting aveugles se produisent lorsqu'un attaquant ne peut pas voir le résultat d'une attaque. Dans ces attaques, la vulnérabilité se trouve généralement sur une page à laquelle seuls les utilisateurs autorisés peuvent accéder.


Un exemple d'attaque cross-site scripting aveugle serait le cas où un nom d'utilisateur est vulnérable au XSS, mais uniquement à partir d'une page d'administration réservée aux utilisateurs de l'administration.


  1. Scripts intersites basés sur le DOM

Les attaques cross-site scripting basées sur le DOM se produisent lorsque ce n'est pas le serveur lui-même qui est vulnérable au XSS, mais plutôt le JavaScript de la page.

Comme JavaScript est utilisé pour ajouter de l'interactivité à la page, les arguments dans l'URL peuvent être utilisés pour modifier la page après son chargement. En modifiant le DOM lorsqu'il ne nettoie pas les valeurs provenant de l'utilisateur, les attaquants peuvent ajouter du code malveillant à une page.


Un exemple d'attaque par script intersite basée sur le DOM serait le cas où le site Web change la sélection de la langue par défaut pour celle fournie dans l'URL.



Comment se prémunir des attaques XSS ?

ll n'est pas facile de prévenir le Cross-site Scripting (XSS). Les techniques de prévention spécifiques dépendent du sous-type de vulnérabilité XSS, du contexte d'utilisation des entrées utilisateur et du cadre de programmation. Cependant, il existe certains principes stratégiques généraux. 


  1. Former et maintenir la sensibilisation

Pour assurer la sécurité de votre application Web, toutes les personnes impliquées dans sa création doivent être conscientes des risques associés aux vulnérabilités XSS. Vous devez dispenser une formation appropriée à tous vos développeurs, votre personnel d'assurance qualité, votre équipe DevOps et vos administrateurs système. 


  1. Ne faites confiance à aucune entrée utilisateur

Traitez toutes les entrées utilisateur comme non fiables. Toute entrée utilisateur qui est utilisée dans le cadre d'une sortie HTML présente un risque de XSS. Traitez les entrées provenant d'utilisateurs authentifiés et/ou internes de la même manière que les entrées publiques.


  1. Utilisez l'échappement/le codage

Utilisez une technique d'échappement/de codage appropriée en fonction de l'endroit où l'entrée de l'utilisateur doit être utilisée : échappement HTML, échappement JavaScript, échappement CSS, échappement URL, etc. 


  1. Assainir le HTML

Si l'entrée de l'utilisateur doit contenir du HTML, vous ne pouvez pas l'échapper/le coder car cela casserait les balises valides. Dans ce cas, utilisez une bibliothèque fiable et vérifiée pour analyser et nettoyer le HTML. Choisissez la bibliothèque en fonction de votre langage de développement, par exemple, HtmlSanitizer pour .NET ou SanitizeHelper pour Ruby on Rails.


  1. Effectuez des scans régulièrement

Les vulnérabilités XSS peuvent être introduites par vos développeurs ou par des bibliothèques/modules/logiciels externes. Vous devez scanner régulièrement vos applications web en utilisant un scanner de vulnérabilité web.