shoucheng3/nahsra__antisamy_cve-2017-14735_1-5-6Bibliothèque Java pour l'assainissement HTML rapide et configurable de sources non fiables. Utilise une analyse pilotée par des politiques pour supprimer les JavaScript et CSS malveillants, prévenant ainsi les attaques XSS dans les applications web.
Une bibliothèque pour effectuer un nettoyage rapide et configurable du HTML provenant de sources non fiables. Prend en charge Java 8 et versions ultérieures.
Une autre façon de le dire : c'est une API qui vous aide à vous assurer que les clients ne fournissent pas de code malveillant dans le HTML qu'ils soumettent pour leur profil, commentaires, etc., qui est ensuite 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 CSS « normaux » peuvent être utilisés de manière malveillante.
Au cours du développement de la série 1.6.x, nous avons identifié et rendu obsolètes un certain nombre de fonctionnalités et d'API. Tous ces éléments obsolètes ont été supprimés dans la version 1.7.0. Ces changements ont tous été suivis dans le ticket : https://github.com/nahsra/antisamy/issues/195. Chacun des changements est décrit ci-dessous :
CssHandler avait 2 constructeurs qui ne comportaient plus le paramètre LinkedList<URI> embeddedStyleSheets. Les deux constructeurs créent désormais une LinkedList<URI> interne vide et la méthode getImportedStylesheetsURIList() peut être utilisée pour obtenir une référence à celle-ci, si nécessaire. Cette fonctionnalité est rarement utilisée, et en fait l'invocation directe de ces constructeurs est également rare, donc ce changement est peu susceptible d'affecter la plupart des utilisateurs d'AntiSamy. Lorsqu'elle est utilisée, normalement une liste vide est passée comme valeur de ce paramètre et cette liste n'est plus jamais utilisée.
La signature CssHandler(Policy, LinkedList<URI>, List<String>, ResourceBundle) a été abandonnée
CssHandler(Policy, List<String>, ResourceBundle)La signature CssHandler(Policy, LinkedList<URI>, List<String>, String, ResourceBundle) a été abandonnée
CssHandler(Policy, List<String>, ResourceBundle, String). REMARQUE : L'ordre des 2 derniers paramètres de cette méthode a été inversé.La prise en charge de XHTML a été abandonnée. AntiSamy ne prend désormais en charge que le HTML. Comme nous pensons qu'il s'agissait d'une fonctionnalité rarement utilisée, nous ne nous attendons pas à ce que cela affecte de nombreux utilisateurs d'AntiSamy.
La validation XML Schema est désormais requise sur les fichiers de politique AntiSamy et ne peut pas être désactivée. Vous devez rendre votre fichier de politique conforme au schéma pour pouvoir l'utiliser avec AntiSamy.
La directive de politique noopenerAndNoreferrerAnchors est désormais activée par défaut. Si elle est désactivée, AntiSamy émet un rappel vous encourageant à l'activer.
Au cours du cycle de vie des mises à niveau d'AntiSamy, la dépendance au parseur HTML a changé, entraînant certaines différences de sortie qui peuvent survenir selon le cas d'utilisation. Tenez-en compte si vous utilisiez certaines versions et obtenez des sorties différentes après une mise à niveau.
Cela peut également s'appliquer au sérialiseur de sortie qui transforme la représentation HTML interne en sortie texte finale de l'outil.
L'équipe AntiSamy a décidé que permettre l'intégration de CSS distants est dangereux et abandonne donc cette fonctionnalité, qui sera supprimée dans une future version. On s'attend à ce qu'il y ait très peu, voire aucun, utilisateur de cette fonctionnalité.
Nous avons ajouté un avertissement de journal (log WARN) si cette fonctionnalité est invoquée. Si c'est votre cas, veuillez désactiver/supprimer cette fonctionnalité en passant au constructeur principal CssScanner qui ne l'active pas.
Tout 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 de votre site pour AntiSamy soit au moins approximativement comparable à l'un des fichiers de politique prédéfinis. Chacun représente un scénario « typique » pour permettre 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 techniques 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, 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 et aucun CSS : <b>, <u>, <i>, <a>, <blockquote>.
En conséquence, nous avons élaboré 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'accentuation ont été autorisées.
eBay est le site d'enchères en ligne le plus populaire de l'univers, pour autant que nous puissions en juger. C'est un site public, donc tout le monde est autorisé à publier des annonces avec un contenu HTML riche. Il n'est pas surprenant qu'étant donné l'attractivité d'eBay en tant que cible, il ait été soumis à quelques attaques XSS complexes. Les annonces sont autorisées à contenir un contenu beaucoup plus riche que, disons, Slashdot — sa surface d'attaque est donc considérablement plus grande.
MySpace était, à la naissance de ce projet, le site de réseautage social le plus populaire. Les utilisateurs étaient autorisés à soumettre à peu près tout le HTML et 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, ce qui explique pourquoi il a été victime de l'infâme 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.
Nous ne connaissons pas de cas d'utilisation possible pour ce fichier de politique. Si vous vouliez 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 lors de l'adaptation des autres fichiers de politique.
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, journalise les messages en mémoire tampon vers la sortie standard. Par conséquent, certains ou tous ces messages de journal peuvent être perdus si une Exception, telle qu'une PolicyException, est levée. Cela peut probablement être corrigé en configurant slf4j-simple pour journaliser vers 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 le métier, sur ce que les utilisateurs peuvent autoriser. La discussion qui détermine l'adaptation doit également prendre en compte la surface d'attaque — qui croît proportionnellement à la taille du fichier de politique.
Les politiques d'exemple peuvent être adaptées et testées en fonction des exigences de chaque balise. Les actions de balise prises en charge qui peuvent être spécifiées sont :
filter : supprimer les balises, mais conserver le contenu.validate : conserver le contenu tant qu'il respecte les règles.remove : supprimer la balise et son contenu.truncate : supprimer les attributs de la balise et toutes les balises enfants, à l'exception de son contenu textuel s'il y en a.encode : similaire à filter mais encode la balise pour le HTML afin de la préserver en tant que texte brut et ses enfants sont remontés d'un niveau dans la hiérarchie.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 y a 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 par des objets File directement 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.
getCleanHTML() - la sortie HTML propre et sûregetCleanXMLDocumentFragment() - le XMLDocumentFragment propre et sûr qui est reflété dans getCleanHTML()getErrorMessages() - une liste de messages d'erreur String -- si cela renvoie 0, cela ne signifie pas qu'il n'y a pas eu d'attaques !getNumberOfErrors() - le nombre de messages d'erreur -- Encore une fois, 0 ne signifie pas que l'entrée était sûre !getScanTime() - retourne le temps d'analyse en secondesNote importante : Il y a eu beaucoup de confusion à propos de la méthode getErrorMessages(). La méthode getErrorMessages() (pas plus que getNumberOfErrors()) ne répond pas subtilement par l'affirmative à la question « cette entrée est-elle sûre ? » si elle retourne une liste vide. Vous devez toujours utiliser l'entrée assainie et il n'y a aucun moyen d'être sûr que l'entrée fournie ne contenait pas d'attaques.
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 qu'AntiSamy ne sait pas toujours rétrospectivement qu'une attaque a été vue. Ainsi, les API getErrorMessages() et getNumberOfErrors() sont là pour aider les utilisateurs à comprendre si leur entrée bien intentionnée répond aux exigences du système, et non pour aider un développeur à détecter la présence d'une attaque.
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 une 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 maintenir la sécurité de nos utilisateurs 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.