Le XSS réfléchi se produit lorsque des scripts malveillants sont inclus dans des URL et immédiatement renvoyés aux utilisateurs sans être correctement nettoyés. Ces attaques nécessitent généralement des techniques d'ingénierie sociale pour convaincre les utilisateurs de cliquer sur des liens malveillants. La prévention passe par la validation des entrées, le codage des sorties et la mise en œuvre d'en-têtes Content Security Policy.
Le cross-site scripting réfléchi se produit lorsqu'une application web récupère une donnée issue d'une requête, généralement un paramètre d'URL, un terme de recherche ou un champ de formulaire, et la renvoie directement dans la réponse HTML sans l'encoder. Si un attaquant fabrique un lien dont le paramètre contient un script, le serveur réfléchit ce script dans la page et le navigateur de la victime l'exécute comme si le site l'avait lui-même écrit. La charge utile n'est stockée nulle part ; elle n'existe que dans cette unique requête, si bien que chaque attaque nécessite un nouveau lien malveillant. Un vecteur typique est une page de résultats de recherche qui affiche votre requête telle quelle, ou une page d'erreur qui répète une valeur non échappée tirée de l'URL.
Parce que le script injecté s'exécute dans le navigateur de la victime sous l'origine même du site, il hérite de la confiance accordée à cette origine. Il peut lire les cookies non HttpOnly, les jetons de session et le contenu de la page, soumettre des formulaires ou modifier ce que voit l'utilisateur, ce qui permet le détournement de session, le vol d'identifiants et le phishing qui semble provenir du domaine légitime. Le XSS réfléchi repose généralement sur l'ingénierie sociale : l'attaquant doit amener la victime à cliquer sur un lien piégé reçu par e-mail, messagerie ou via une publicité malveillante, ce qui vise souvent les utilisateurs connectés d'une banque, d'une messagerie web ou de panneaux d'administration. Un seul paramètre vulnérable peut compromettre n'importe quel compte dont le propriétaire ouvre le lien.
Les défenses principales incombent aux développeurs : validez les entrées et appliquez un encodage de sortie tenant compte du contexte pour que les valeurs réfléchies s'affichent comme du texte, jamais comme du balisage ou du script. Une Content Security Policy ajoute une seconde couche en restreignant les scripts autorisés à s'exécuter, et l'échappement automatique des frameworks règle la plupart des cas par défaut. cside ne remplace pas l'encodage de sortie ; son objet est constitué des scripts third-party qu'une page charge. Lorsqu'un point d'ancrage XSS ou un script fournisseur compromis tente de charger ou d'exfiltrer des données via le navigateur, le méthode Script de cside inspecte la charge utile JavaScript réelle, peut bloquer ce comportement en temps réel et conserve une trace forensique, ce qui répond également aux exigences de surveillance des scripts PCI DSS 6.4.3 et 11.6.1.
Son rayon d'action est généralement plus restreint, car la charge utile n'est pas enregistrée sur le serveur : elle n'affecte donc que les utilisateurs qui ouvrent un lien spécifiquement conçu, et non toute personne qui consulte une page. Mais les capacités dans le navigateur sont identiques, et face à une cible connectée de grande valeur, un seul clic peut suffire à détourner un compte.
Non. L'attribut HttpOnly masque seulement un cookie au JavaScript, ce qui limite le vol de jeton, mais un script réfléchi peut toujours agir au sein de la session, lire les données de la page, envoyer des requêtes et défigurer l'interface. HttpOnly est une atténuation utile, pas une solution ; vous avez toujours besoin d'un encodage de sortie et d'une CSP robuste.
We answer client-side security questions every day. Bring yours.