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.