shoucheng3/nahsra__antisamy_cve-2017-14735_1-5-6Java-Bibliothek für schnelle, konfigurierbare HTML-Bereinigung aus nicht vertrauenswürdigen Quellen. Verwendet richtlinienbasiertes Scannen, um bösartiges JavaScript und CSS zu entfernen und XSS-Angriffe in Webanwendungen zu verhindern.
Eine Bibliothek für schnelle, konfigurierbare Bereinigung von HTML aus nicht vertrauenswürdigen Quellen. Unterstützt Java 8+.
Anders ausgedrückt: Es ist eine API, die Ihnen hilft sicherzustellen, dass Clients keinen bösartigen Code in das HTML einschleusen, das sie für ihr Profil, Kommentare usw. liefern und das auf dem Server gespeichert wird. Der Begriff „bösartiger Code“ bezieht sich bei Webanwendungen meist auf „JavaScript“. Cascading Stylesheets werden größtenteils nur dann als bösartig angesehen, wenn sie JavaScript aufrufen. Es gibt jedoch viele Situationen, in denen „normales“ HTML und CSS auf bösartige Weise verwendet werden können.
Im Laufe der Entwicklung der 1.6.x-Serie haben wir eine Reihe von Funktionen und APIs identifiziert und als veraltet (deprecated) markiert. Diese veralteten Elemente wurden alle in der Version 1.7.0 entfernt. Alle Änderungen wurden im Ticket https://github.com/nahsra/antisamy/issues/195 erfasst. Die einzelnen Änderungen werden im Folgenden beschrieben:
CssHandler hatte 2 Konstruktoren, bei denen der Parameter LinkedList<URI> embeddedStyleSheets entfernt wurde. Beide Konstruktoren erstellen nun eine leere interne LinkedList<URI>, und die Methode getImportedStylesheetsURIList() kann verwendet werden, um bei Bedarf eine Referenz darauf zu erhalten. Diese Funktion wird selten genutzt, und auch die direkte Verwendung dieser Konstruktoren ist selten, sodass diese Änderung die meisten AntiSamy-Benutzer wahrscheinlich nicht betrifft. Wenn sie verwendet wird, wird normalerweise eine leere Liste als Parameterwert übergeben, die danach nie wieder verwendet wird.
Die Signatur CssHandler(Policy, LinkedList<URI>, List<String>, ResourceBundle) wurde entfernt
CssHandler(Policy, List<String>, ResourceBundle)Die Signatur CssHandler(Policy, LinkedList<URI>, List<String>, String, ResourceBundle) wurde entfernt
CssHandler(Policy, List<String>, ResourceBundle, String). HINWEIS: Die Reihenfolge der letzten 2 Parameter dieser Methode wurde umgedreht.Die Unterstützung für XHTML wurde entfernt. AntiSamy unterstützt jetzt nur noch HTML. Da wir davon ausgehen, dass dies eine selten genutzte Funktion war, erwarten wir nicht, dass dies viele AntiSamy-Benutzer betrifft.
Die XML-Schema-Validierung ist für AntiSamy-Policy-Dateien nun erforderlich und kann nicht deaktiviert werden. Sie müssen Ihre Policy-Datei schema-konform gestalten, um sie mit AntiSamy verwenden zu können.
Die Policy-Direktive noopenerAndNoreferrerAnchors ist jetzt standardmäßig aktiviert. Wenn sie deaktiviert ist, gibt AntiSamy einen Hinweis aus, der Sie ermutigt, sie zu aktivieren.
Im Laufe des Upgrade-Lebenszyklus von AntiSamy gab es Änderungen an der HTML-Parser-Abhängigkeit, die je nach Anwendungsfall zu einigen Unterschieden in der Ausgabe führen können. Bedenken Sie dies, wenn Sie bestimmte Versionen verwendet haben und nach einem Upgrade andere Ausgaben erhalten.
Dies kann auch für den Ausgabe-Serialisierer gelten, der die interne HTML-Darstellung in die endgültige Textausgabe des Tools umwandelt.
Das AntiSamy-Team hat entschieden, dass die Möglichkeit, eingebettetes entferntes CSS zu erlauben, gefährlich ist. Daher wird diese Funktion als veraltet eingestuft und in einer zukünftigen Version entfernt. Es wird erwartet, dass es nur sehr wenige, wenn überhaupt, Benutzer dieser Funktion gibt.
Wir haben eine Log-WARNung hinzugefügt, die ausgegeben wird, wenn diese Funktion aufgerufen wird. Falls Sie sie verwenden, deaktivieren/entfernen Sie diese Funktion bitte, indem Sie auf den primären CssScanner-Konstruktor wechseln, der diese Funktion nicht aktiviert.
Fügen Sie zuerst die Abhängigkeit von Maven hinzu:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
Die Wahrscheinlichkeit ist groß, dass der Anwendungsfall Ihrer Website für AntiSamy zumindest grob mit einem der vordefinierten Policy-Dateien vergleichbar ist. Jede davon stellt ein „typisches“ Szenario dar, in dem Benutzern erlaubt wird, HTML- (und möglicherweise CSS-)Formatierungsinformationen bereitzustellen. Schauen wir uns die verschiedenen Policy-Dateien an:
Slashdot ist eine Technik-Nachrichtenseite, die es Benutzern erlaubt, anonym auf Nachrichtenbeiträge mit sehr begrenztem HTML-Markup zu antworten. Slashdot ist nicht nur eine der coolsten Seiten überhaupt, sondern auch eine, die vielen verschiedenen erfolgreichen Angriffen ausgesetzt war. Die Regeln für Slashdot sind ziemlich streng: Benutzer können nur die folgenden HTML-Tags und kein CSS einreichen: <b>, <u>, <i>, <a>, <blockquote>.
Dementsprechend haben wir eine Policy-Datei erstellt, die ziemlich ähnliche Funktionen erlaubt. Alle Textformatierungs-Tags, die direkt auf Schriftart, Farbe oder Hervorhebung wirken, wurden erlaubt.
eBay ist die beliebteste Online-Auktionsseite im Universum, soweit wir das beurteilen können. Es ist eine öffentliche Seite, auf der jeder Einträge mit umfangreichem HTML-Inhalt veröffentlichen darf. Es ist nicht überraschend, dass eBay als Angriffsziel aufgrund seiner Attraktivität einigen komplexen XSS-Angriffen ausgesetzt war. Einträge dürfen viel mehr umfangreiche Inhalte enthalten als beispielsweise Slashdot – daher ist die Angriffsfläche erheblich größer.
MySpace war zum Zeitpunkt der Entstehung dieses Projekts die beliebteste soziale Netzwerkseite. Benutzern war es erlaubt, so ziemlich das gesamte HTML und CSS einzureichen, das sie wollten – solange es kein JavaScript enthielt. MySpace verwendete eine Wort-Blacklist, um das HTML der Benutzer zu validieren, weshalb es dem berüchtigten Samy-Wurm ausgesetzt war. Der Samy-Wurm, der Fragmentierungsangriffe mit einem Wort kombinierte, das hätte auf der Blacklist stehen sollen (eval), war die Inspiration für dieses Projekt.
Wir kennen keinen möglichen Anwendungsfall für diese Policy-Datei. Wenn Sie jedes gültige HTML- und CSS-Element erlauben möchten (jedoch ohne JavaScript oder offensichtliche CSS-basierte Phishing-Angriffe), können Sie diese Policy-Datei verwenden. Nicht einmal MySpace war so verrückt. Sie dient jedoch als gute Referenz, da sie Basisregeln für jedes Element enthält. Sie können sie also als Wissensbasis verwenden, wenn Sie die anderen Policy-Dateien anpassen.
AntiSamy enthält jetzt die Bibliothek slf4j-simple für seine Protokollierung, aber AntiSamy-Benutzer können bei Bedarf eine alternative slf4j-kompatible Protokollierungsbibliothek importieren und verwenden. Sie können slf4j-simple bei Bedarf auch ausschließen.
WARNUNG: Die Verwendung von slf4j-simple durch AntiSamy ohne Konfigurationsdatei protokolliert Nachrichten gepuffert auf der Standardausgabe. Daher können einige oder alle dieser Logmeldungen verloren gehen, wenn eine Exception, wie z. B. eine PolicyException, geworfen wird. Dies kann wahrscheinlich behoben werden, indem slf4j-simple so konfiguriert wird, dass es auf die Standardfehlerausgabe protokolliert, oder indem ein alternativer slf4j-Logger verwendet wird, der dies tut.
Möglicherweise möchten Sie AntiSamy in einer Standardkonfiguration einsetzen, aber es ist ebenso wahrscheinlich, dass eine Website strenge, geschäftsbasierte Regeln dafür haben möchte, was Benutzer erlauben dürfen. Bei der Diskussion, die über die Anpassung entscheidet, sollte auch die Angriffsfläche berücksichtigt werden – die proportional zur Policy-Datei wächst.