shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1Bibliothèque Java pour le nettoyage rapide et configurable de HTML non fiable afin de prévenir les attaques de cross-site scripting (XSS). Utilise une analyse pilotée par des politiques pour assainir le balisage fourni par l'utilisateur.
Une bibliothèque permettant un nettoyage rapide et configurable du HTML provenant de sources non fiables. Prend en charge Java 7+.
Une autre façon de le dire serait : c'est une API qui vous aide à vous assurer que les clients ne fournissent pas de code malveillant embarqué dans le HTML qu'ils soumettent pour leur profil, leurs commentaires, etc., et qui est persisté sur le serveur. Le terme « code malveillant » dans le contexte des applications web signifie généralement « JavaScript ». La plupart du temps, les feuilles de style en cascade ne sont considérées comme malveillantes que lorsqu'elles invoquent JavaScript. Cependant, il existe de nombreuses situations où du HTML et du CSS « normaux » peuvent être utilisés de manière malveillante.
D'abord, ajoutez la dépendance depuis Maven :
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
Il y a de fortes chances que le cas d'utilisation d'AntiSamy sur votre site soit au moins approximativement comparable à l'un des fichiers de politique prédéfinis. Ils représentent chacun un scénario « typique » permettant aux utilisateurs de fournir des informations de formatage HTML (et éventuellement CSS). Examinons les différents fichiers de politique :
Slashdot est un site d'actualités technologiques qui permet aux utilisateurs de répondre anonymement aux articles avec un balisage HTML très limité. Slashdot n'est pas seulement l'un des sites les plus cool qui soient, c'est aussi l'un de ceux qui ont subi de nombreuses attaques réussies. Les règles de Slashdot sont assez strictes : les utilisateurs ne peuvent soumettre que les balises HTML suivantes, sans CSS : <b>, <u>, <i>, <a>, <blockquote>.
En conséquence, nous avons créé un fichier de politique qui autorise des fonctionnalités assez similaires. Toutes les balises de formatage de texte qui agissent directement sur la police, la couleur ou l'emphase ont été autorisées.
eBay est le site d'enchères en ligne le plus populaire de l'univers, pour autant que je sache. C'est un site public, donc tout le monde est autorisé à publier des annonces avec un contenu HTML riche. Il n'est pas surprenant, étant donné l'attractivité d'eBay en tant que cible, qu'il ait été soumis à quelques attaques XSS complexes. Les annonces peuvent contenir un contenu beaucoup plus riche que, disons, Slashdot — sa surface d'attaque est donc considérablement plus grande.
MySpace était, au moment de la naissance de ce projet, le site de réseau social le plus populaire. Les utilisateurs étaient autorisés à soumettre à peu près tout le HTML et le CSS qu'ils voulaient — tant que cela ne contenait pas de JavaScript. MySpace utilisait une liste noire de mots pour valider le HTML des utilisateurs, c'est pourquoi il a été victime du tristement célèbre ver Samy. Le ver Samy, qui utilisait des attaques par fragmentation combinées à un mot qui aurait dû être mis sur liste noire (eval), a été l'inspiration de ce projet.
Je ne connais pas de cas d'utilisation possible pour ce fichier de politique. Si vous voulez autoriser chaque élément HTML et CSS valide (mais sans JavaScript ni attaques de phishing flagrantes liées au CSS), vous pouvez utiliser ce fichier de politique. Même MySpace n'était pas aussi fou. Cependant, il constitue une bonne référence car il contient des règles de base pour chaque élément, vous pouvez donc l'utiliser comme base de connaissances pour adapter les autres fichiers de politique.
En travaillant sur des améliorations de la définition de schéma XML (XSD) d'AntiSamy pour les fichiers de politique AntiSamy, nous avons remarqué qu'AntiSamy n'appliquait pas réellement la XSD. Nous avons donc CHANGÉ le comportement par défaut à partir d'AntiSamy 1.6.0 afin d'appliquer le schéma et de ne pas continuer si la politique AntiSamy est invalide. Cependant ...
nous reconnaissons qu'il se peut que les développeurs ne soient pas en mesure de corriger immédiatement leurs politiques AntiSamy si elles ne sont pas conformes, tout en souhaitant tout de même mettre à niveau AntiSamy pour bénéficier des améliorations de sécurité, des nouvelles fonctionnalités et des corrections de bogues. C'est pourquoi nous avons prévu deux moyens de désactiver (temporairement !) la validation du schéma :
Définissez la propriété système Java : owasp.validator.validateschema à false. Cela peut être fait en ligne de commande (par exemple, -Dowasp.validator.validateschema=false) ou via le fichier de propriétés système Java. Aucune de ces méthodes ne nécessite de modification de code.
Modifiez le code utilisant AntiSamy pour invoquer : Policy.setSchemaValidation(false) avant de charger la politique AntiSamy. Il s'agit d'un appel statique : une fois désactivée, la validation est désactivée pour toutes les nouvelles instances de Policy.
Pour encourager les utilisateurs d'AntiSamy à n'utiliser que des politiques conformes à la XSD, AntiSamy enregistrera toujours une sorte d'avertissement lorsque la validation du schéma est désactivée. Il émettra soit un WARN indiquant que la politique n'est pas conforme afin qu'elle puisse être corrigée, soit un WARN indiquant que la politique est conforme, mais que la validation du schéma est DÉSACTIVÉE, et qu'elle doit donc être réactivée (c'est-à-dire cesser de la désactiver). Nous avons également ajouté une journalisation de niveau INFO lorsque les schémas AntiSamy sont chargés et validés.
La possibilité de désactiver la nouvelle fonctionnalité de validation du schéma est destinée à être temporaire, afin de faciliter la transition vers des fichiers de politique AntiSamy correctement valides. Nous prévoyons de supprimer cette fonctionnalité dans la prochaine version majeure. Nous estimons que cela se produira vers le milieu ou la fin de 2022, donc pas tout de suite. L'idée est de laisser aux équipes de développement qui utilisent AntiSamy directement, ou via d'autres bibliothèques comme ESAPI, suffisamment de temps pour rendre leurs fichiers de politique conformes au schéma avant que la validation du schéma ne devienne obligatoire.
Cela a été rapidement corrigé en 1.6.1 pour n'utiliser que les API slf4j. AntiSamy inclut désormais la bibliothèque slf4j-simple pour sa journalisation, mais les utilisateurs d'AntiSamy peuvent importer et utiliser une autre bibliothèque de journalisation compatible slf4j s'ils le préfèrent. Ils peuvent également exclure slf4j-simple s'ils le souhaitent.
AVERTISSEMENT : L'utilisation de slf4j-simple par AntiSamy, sans fichier de configuration, enregistre les messages de manière tamponnée sur la sortie standard. Par conséquent, certains ou tous ces messages de journalisation peuvent être perdus si une exception, telle qu'une PolicyException, est levée. Cela peut probablement être corrigé en configurant slf4j-simple pour journaliser sur la sortie d'erreur standard à la place, ou en utilisant un autre logger slf4j qui le fait.
Vous souhaiterez peut-être déployer AntiSamy dans une configuration par défaut, mais il est tout aussi probable qu'un site veuille avoir des règles strictes, dictées par son activité, pour ce que les utilisateurs peuvent autoriser. La discussion qui détermine l'adaptation doit également prendre en compte la surface d'attaque, qui augmente en proportion relative du fichier de politique.