Les charges utiles polyglottes sont des chaînes d'attaque valides dans plusieurs contextes, pouvant potentiellement contourner les filtres de sécurité. Par exemple, une chaîne peut être à la fois valide JavaScript et valide en HTML. Ces charges utiles sophistiquées peuvent exploiter les différences entre les analyseurs syntaxiques et échapper à la désinfection. La prévention nécessite une validation des entrées et un encodage des sorties adaptés au contexte.
Une charge utile polyglotte est une chaîne unique conçue pour être valide, et pour faire quelque chose d'utile à l'attaquant, dans plus d'un contexte d'analyse à la fois. Un exemple web classique est une séquence qui se comporte comme du texte ordinaire en HTML, comme une valeur d'attribut, et comme du JavaScript exécutable, de sorte que quelle que soit la manière dont une page interprète l'entrée, une partie de celle-ci déclenche encore l'exécution du script. Les attaquants les construisent en combinant des fragments qui terminent un contexte et en ouvrent un autre, en recourant à des astuces de commentaires et à des caractères que différents analyseurs traitent différemment. La même idée apparaît dans les formats de fichiers, où un fichier est simultanément une image valide et un script ou une archive valide.
Les polyglottes existent pour déjouer les défenses propres à un contexte. De nombreux filtres et assainisseurs d'entrée supposent qu'ils savent où aboutiront les données de l'utilisateur, un corps HTML, une URL, une chaîne JavaScript, et n'encodent que pour ce cas. Une charge utile qui reste valide dans plusieurs contextes échappe aux filtres réglés pour un seul, et exploite les différences entre la façon dont un assainisseur côté serveur et l'analyseur du navigateur lisent les mêmes octets. Cela fait des polyglottes un favori pour le XSS qui survit aux règles d'un pare-feu applicatif web (WAF) et pour les envois de fichiers qui passent un contrôle d'image mais s'exécutent comme un script. Une seule chaîne réutilisable peut sonder de nombreux points d'injection, réduisant l'effort nécessaire pour en trouver un qui se déclenche.
La défense commence par un encodage de sortie tenant compte du contexte : encodez les données pour le point de destination exact où elles aboutissent (HTML, attribut, URL, JavaScript, CSS) plutôt que d'appliquer un seul filtre générique, et privilégiez les API DOM sûres comme textContent plutôt que innerHTML. Validez les envois de fichiers par type de contenu et réencodez les fichiers côté serveur afin qu'un polyglotte ne puisse pas conserver sa seconde identité. Une Content Security Policy stricte limite ce qu'un script injecté peut faire même si une charge utile parvient à aboutir. cside complète ces contrôles en analysant le comportement des scripts qui s'exécutent réellement dans le navigateur et en bloquant l'activité malveillante en temps réel, plutôt que de se fier à des filtres qu'une chaîne astucieusement encodée peut contourner.
Une charge utile XSS standard cible un contexte connu. Un polyglotte est conçu pour rester valide dans plusieurs contextes simultanément, de sorte que l'attaquant n'a pas besoin de savoir exactement comment l'application analysera l'entrée ; la même chaîne fonctionne qu'elle aboutisse dans du HTML, un attribut ou du JavaScript.
Oui. Les polyglottes de fichiers sont conçus pour qu'un seul fichier satisfasse deux spécifications de format à la fois, par exemple un GIF valide qui est aussi du JavaScript exécutable. Ils servent à contourner les filtres d'envoi ou les contrôles de type de contenu qui ne valident que par rapport à un seul format attendu.
We answer client-side security questions every day. Bring yours.