Le Cross-Site Scripting est une faille de sécurité qui permet à des pirates d'injecter des scripts malveillants dans des pages web consultées par d'autres utilisateurs. Ces scripts peuvent voler des jetons de session, des cookies et d'autres données sensibles, ou effectuer des actions au nom de l'utilisateur. Il existe plusieurs formes de Cross-Site Scripting : réfléchi (via des paramètres URL), stocké (dans des bases de données) et basé sur le DOM (JavaScript côté client). Pour le prévenir, il faut valider correctement les entrées, encoder les sorties et mettre en œuvre une politique de sécurité du contenu.
Le cross-site scripting (XSS) est une vulnérabilité qui permet à un attaquant d'injecter du JavaScript dans une page que d'autres utilisateurs chargent ensuite. Si une application prend une entrée, un terme de recherche, un commentaire, un paramètre d'URL, et l'affiche dans la page sans encodage approprié, un attaquant peut fournir du script au lieu de texte. Ce script s'exécute dans le navigateur de la victime avec la session de la victime, ce qui lui permet de voler des cookies, de capturer des frappes clavier ou d'agir en tant qu'utilisateur.
Il existe trois formes classiques. Le XSS stocké enregistre le payload sur le serveur, dans un commentaire ou un champ de profil, de sorte qu'il touche chaque visiteur. Le XSS réfléchi renvoie le payload via le serveur au moyen d'un lien piégé. Le XSS basé sur le DOM n'atteint jamais le serveur : du JavaScript vulnérable côté client écrit des données contrôlées par l'attaquant dans la page. Chacun demande une défense légèrement différente, mais tous se terminent par l'exécution du code de l'attaquant dans un contexte de confiance.
Les défenses fondamentales sont l'encodage contextuel de la sortie, la validation des entrées et une Content Security Policy solide qui limite ce que le script injecté peut faire. Comme le XSS aboutit à l'exécution de JavaScript inattendu dans le navigateur, la surveillance côté client ajoute une couche utile : cside peut signaler lorsqu'une page se met à exécuter un script qui lit des champs sensibles ou exfiltre des données, détectant l'exploitation même lorsqu'une faille d'injection précise a échappé à la revue de code.
Tout ce que le navigateur de l'utilisateur peut faire dans cette session : lire et exfiltrer des cookies ou des jetons, capturer ce que l'utilisateur tape, y compris mots de passe et numéros de carte, réécrire le contenu de la page pour du phishing, ou effectuer des requêtes authentifiées en tant que victime. La gravité dépend des privilèges de l'utilisateur affecté.
Une CSP bien configurée rend l'exploitation nettement plus difficile en restreignant les scripts en ligne et les sources non fiables, mais c'est une mesure d'atténuation, pas un remède. Les mauvaises configurations, les domaines autorisés mais détournables et les points d'injection basés sur le DOM restent exploitables. La CSP fonctionne mieux combinée à un encodage de sortie correct.
We answer client-side security questions every day. Bring yours.