INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q094 — Définir XSS réfléchi, stocké et DOM-based.
Merci pour cette question portant sur la sécurité des applications web. Voici une définition précise des trois grandes familles de failles XSS (Cross-Site Scripting). XSS réfléchi (reflected XSS) Le XSS réfléchi se produit lorsque des données non fiables, généralement issues de la requête HTTP (paramètres d'URL, champs de formulaire), sont renvoyées par le serveur dans la réponse sans avoir été correctement neutralisées. L'attaque est dite réfléchie car le script malveillant fait l'aller-retour : il est envoyé au serveur, qui le renvoie immédiatement dans la page. L'utilisateur doit être piégé pour cliquer sur un lien spécialement construit, souvent via un courriel d'hameçonnage. Le script s'exécute alors dans le contexte de la victime, avec les privilèges de la page légitime. XSS stocké (stored XSS) Le XSS stocké, aussi appelé XSS persistant, survient lorsque le script malveillant est enregistré durablement sur le serveur, par exemple dans une base de données, un forum, un champ de commentaire ou un profil utilisateur. À chaque consultation de la page concernée, le script est rejoué et s'exécute chez tous les visiteurs. C'est la variante la plus dangereuse : elle ne nécessite pas de piéger individuellement chaque victime, et elle peut toucher un très grand nombre d'utilisateurs sur une longue période. XSS DOM-based Le XSS basé sur le DOM se distingue des deux précédents par le fait que le serveur n'est pas impliqué dans l'injection. Ici, la vulnérabilité réside dans le code JavaScript exécuté côté client, qui lit une source non fiable (par exemple la propriété location.search, location.hash, document.referrer ou document.cookie) et l'écrit dans une destination sensible du DOM (innerHTML, document.write, eval, etc.) sans validation. Le script malveillant est donc construit et exécuté entièrement dans le navigateur de la victime, sans que le serveur ne voie jamais la charge utile. Éléments de comparaison La distinction essentielle entre les trois formes tient au lieu où se produit l'injection et à sa persistance. Le XSS réfléchi et le XSS stocké sont des failles côté serveur, la différence étant la persistance (éphémère pour le réfléchi, durable pour le stocké). Le XSS DOM-based est une faille purement côté client, indépendante du traitement serveur. Toutes trois partagent le même objectif final : exécuter du code arbitraire dans le contexte de confiance de la victime, ce qui peut conduire au vol de session, à la capture de données sensibles ou à la compromission de la page. Confiance : 92 %. Cette définition repose sur des notions standard et bien établies de la sécurité des applications web, que je connais avec une grande fiabilité. La marge restante tient au fait que je l'énonce de mémoire, sans source consultable dans cette conversation, et que les frontières entre ces catégories peuvent parfois se recouper dans des cas pratiques complexes. Je reste à votre disposition pour approfondir les mécanismes de détection ou les contre-mesures associées à chacune de ces failles.
Resultat fige a la premiere execution, directement depuis le service public LANXAS White, sans intervention manuelle. Cette page est permanente et peut etre re-consultee pour verification.