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.
Utiliser AntiSamy est simple. Voici un exemple d'invocation d'AntiSamy avec un fichier de politique :
import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
Il existe plusieurs façons de créer un objet Policy. La méthode getInstance() peut accepter l'un des éléments suivants :
StringFileInputStreamPolicy peuvent également être référencés par nom de fichier en passant un second argument à la méthode AntiSamy#scan(), comme le montrent les exemples suivants :AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
Enfin, les fichiers de politique peuvent également être référencés directement par des objets File dans le second paramètre :
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
L'objet CleanResults fournit beaucoup d'éléments utiles.
getErrorMessages() - une liste de messages d'erreur de type String -- si cela renvoie 0, cela ne signifie pas qu'il n'y a pas eu d'attaques !getCleanHTML() - la sortie HTML propre et sûregetCleanXMLDocumentFragment() - le XMLDocumentFragment propre et sûr qui se reflète dans getCleanHTML()getScanTime() - renvoie le temps d'analyse en secondesRemarque importante : Il y a eu beaucoup de confusion à propos de la méthode getErrorMessages(). La méthode getErrorMessages() ne répond pas subtilement par l'affirmative à la question « cette entrée est-elle sûre ? » si elle renvoie une liste vide. Vous devez toujours utiliser l'entrée assainie et il n'y a aucun moyen d'être certain que l'entrée fournie ne contenait aucune attaque.
Le processus de sérialisation et de désérialisation, essentiel à l'efficacité de l'assainisseur, est volontairement avec perte et filtrera les attaques via un certain nombre de vecteurs d'attaque. Malheureusement, l'un des compromis de cette stratégie est que nous ne savons pas toujours rétrospectivement qu'une attaque a été observée. Ainsi, l'API getErrorMessages() est là pour aider les utilisateurs à comprendre comment leur entrée bien intentionnée répond aux exigences du système, et non pour aider un développeur à détecter si une attaque était présente.
Une documentation supplémentaire est disponible sur la page wiki de ce projet Github : https://github.com/nahsra/antisamy/wiki et sur la page du projet OWASP AntiSamy : https://owasp.org/www-project-antisamy/
Si vous avez trouvé un bug, créez un problème (issue) dans le dépôt AntiSamy : https://github.com/nahsra/antisamy/issues
Si vous avez trouvé une vulnérabilité dans AntiSamy, commencez par rechercher dans la liste des issues (voir ci-dessus) si elle a déjà été signalée. Si ce n'est pas le cas, veuillez contacter directement Dave Wichers (dave.wichers at owasp.org). Veuillez ne pas signaler les vulnérabilités via les issues GitHub, car nous souhaitons garder nos utilisateurs en sécurité pendant qu'un correctif est implémenté et déployé. Si vous souhaitez être reconnu pour avoir trouvé la vulnérabilité, veuillez suivre ce processus.
Plus de détails sont disponibles dans le fichier : SECURITY.md.
Vous pouvez compiler et tester à partir des sources assez facilement :
$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package
Publié sous la licence BSD-3-Clause comme spécifié ici : LICENSE.