Le XSS (Cross-Site Scripting) stocké se produit lorsque des scripts malveillants sont stockés de manière permanente sur les serveurs cibles, puis affichés aux utilisateurs qui accèdent aux pages concernées. Ce type de XSS est particulièrement dangereux, car il affecte tous les visiteurs de la page compromise. Pour le prévenir, il est nécessaire de mettre en place une validation des entrées, un encodage des sorties et des politiques de sécurité du contenu appropriés.
Le cross-site scripting stocké, aussi appelé XSS persistant, survient lorsqu'une application accepte un contenu fourni par un attaquant, l'enregistre, puis le sert ultérieurement à d'autres utilisateurs sans l'encoder correctement. Le script malveillant est écrit une seule fois, dans un champ de commentaire, un avis produit, un message de forum, un profil utilisateur ou un ticket de support, puis s'exécute dans le navigateur de chaque visiteur qui charge la page concernée. Contrairement au XSS réfléchi, aucun lien fabriqué ni aucune ingénierie sociale par victime n'est nécessaire ; la charge utile attend sur le serveur et se déclenche automatiquement. Comme le balisage injecté fait désormais partie du contenu normal de la page, il peut persister aussi longtemps que l'enregistrement existe et continuer à infecter de nouveaux visiteurs.
Le XSS stocké est la variante de XSS la plus dangereuse car elle s'auto-propage et touche toute personne qui consulte la page empoisonnée. Une charge utile placée dans un fil populaire ou un profil partagé peut s'exécuter dans des milliers de sessions, et si elle aboutit là où un administrateur la consulte, elle peut dégénérer en prise de contrôle complète du compte ou de l'application. S'exécutant sous l'origine du site, le script peut voler des jetons de session et des cookies non HttpOnly, capturer les frappes clavier et les données de formulaire, agir à la place de la victime ou se propager dans d'autres enregistrements. Les vers XSS historiques se sont répandus exactement de cette manière, s'ajoutant à chaque profil qu'ils touchaient et infectant de nouveaux utilisateurs à chaque affichage.
La défense relève avant tout du serveur et du code : validez et nettoyez les entrées en amont, encodez la sortie selon son contexte exact en aval, et assainissez tout HTML riche avec un sanitizer éprouvé avant qu'il n'atteigne le DOM. Une Content Security Policy limite ce qu'un script injecté peut faire même si l'un d'eux passe entre les mailles. cside ne remplace pas ces contrôles pour le code de votre propre application. Là où il aide, c'est au niveau de l'exécution dans le navigateur : il achemine les scripts third-party via un méthode Script, analyse la charge utile JavaScript qui s'exécute réellement, peut bloquer les comportements malveillants tels que l'exfiltration de données en temps réel, et conserve des traces forensiques qui répondent à PCI DSS 6.4.3 et 11.6.1.
Parce que la charge utile est enregistrée côté serveur et servie à toute personne qui ouvre la page concernée, elle ne nécessite ni lien ni clic propre à chaque victime. Une seule injection peut s'exécuter dans la session de chaque visiteur, et si un administrateur la consulte, l'attaquant peut obtenir un accès élevé, ce qui confère au XSS stocké un rayon d'action bien plus vaste.
Non. La vulnérabilité tient à la manière dont le contenu est rendu, pas à l'endroit où il est conservé. Si des données stockées sont ensuite insérées dans une page en tant que HTML sans encodage ni assainissement, elles s'exécuteront. Le Markdown peut même accroître le risque s'il autorise le HTML brut ou des liens dangereux, la sortie doit donc toujours être assainie.
We answer client-side security questions every day. Bring yours.