Les biographies de profil fournies par les utilisateurs s'affichent sans échappement, et l'une contient une balise `<script>`. Quelle est la bonne correction ?
Réponse courte
Le XSS stocké se corrige en encodant les données pour le contexte exact où elles sont rendues (corps HTML, attribut, JavaScript, URL) afin que le navigateur les traite comme du texte, avec une Content-Security-Policy en seconde couche. Mettre le mot « script » en liste noire se contourne trivialement via des gestionnaires d'événements, la casse mixte et les encodages. Vous ne pouvez pas forcer vos utilisateurs à désactiver JavaScript. Demander aux utilisateurs de ne pas saisir de HTML n'est pas un contrôle applicable. Encodez à la sortie, à chaque rendu.
La bio est stockée puis rendue dans une page sans être encodée, donc une balise <script> qu'elle contient s'exécute dans le navigateur de chaque visiteur. C'est du cross-site scripting stocké (persistant) — une seule charge injectée frappe chaque utilisateur qui charge le profil. La cause profonde est que les données sont interprétées comme du balisage au moment du rendu.
La bonne correction : encodage de sortie contextuel
Le XSS est un problème de rendu, alors corrigez-le là où les données rencontrent la page : encodez à la sortie, pour le contexte spécifique.
- Dans un contexte de corps HTML, encodez
<,>,&, etc., pour que le navigateur affiche le texte au lieu d'analyser une balise. - Dans un contexte d'attribut HTML, de JavaScript ou d'URL, l'encodage correct diffère — utiliser le mauvais laisse encore une faille.
Les frameworks modernes échappent automatiquement par défaut ; le bug apparaît généralement là où quelqu'un recourt à une échappatoire de HTML brut. Ajoutez une Content-Security-Policy en défense en profondeur afin que, même si un encodage est oublié, les scripts en ligne et non fiables soient bloqués.
Pourquoi les distracteurs sont faux
- Retirer le mot « script » est une liste noire d'entrée, contournée trivialement : une balise
imgavec un gestionnaireonerror, une balisesvgaveconload, la casse mixte, les entités HTML et des dizaines d'autres vecteurs ne contiennent aucun « script » littéral. - Dire aux utilisateurs de désactiver JavaScript est absurde comme contrôle — vous ne pilotez pas les navigateurs de vos utilisateurs, et l'application dépend de toute façon du JS.
- Demander aux utilisateurs de ne pas saisir de HTML est une requête, pas une application ; l'attaquant l'ignore tout simplement.
Ce que l'examinateur cherche à évaluer
Si vous savez que le XSS se corrige à la sortie, dans le bon contexte, et non en filtrant les entrées contre une liste de refus, et si vous superposez un CSP sans le confondre avec la correction principale. Les bons candidats notent que la validation des entrées et l'assainissement de HTML de confiance ont leur place (pour les champs de texte enrichi), mais que l'encodage de sortie contextuel est le contrôle fiable et universel.
Questions de suivi probables
- Pourquoi l'encodage de sortie dépend-il du contexte — en quoi l'encodage pour un attribut HTML diffère-t-il de celui d'une chaîne JS ?
- Qu'apporte une Content-Security-Policy, et pourquoi ne remplace-t-elle pas l'encodage ?
- Quand l'assainissement des entrées (par ex. un sanitizer HTML) est-il approprié plutôt que l'encodage ?