shoucheng3/nahsra__antisamy_cve-2017-14735_1-5-6
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.
Beispiel-Policies können basierend auf den Anforderungen für jedes Tag angepasst und getestet werden. Die unterstützten Tag-Aktionen, die angegeben werden können, sind:
filter: Tags entfernen, aber Inhalt behalten.validate: Inhalt behalten, solange er die Regeln erfüllt.remove: Tag und Inhalt entfernen.truncate: Tag-Attribute und alle untergeordneten Tags entfernen, außer seinem Textinhalt, falls vorhanden.encode: ähnlich wie filter, aber es kodiert das Tag für HTML, um es als Rohtext zu erhalten, und seine Kinder werden eine Ebene höher in der Hierarchie verschoben.Die Verwendung von AntiSamy ist einfach. Hier ist ein Beispiel für den Aufruf von AntiSamy mit einer Policy-Datei:
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
Es gibt einige Möglichkeiten, ein Policy-Objekt zu erstellen. Die Methode getInstance() kann eines der folgenden Argumente akzeptieren:
String-DateinamenFile-ObjektInputStreamPolicy-Dateien können auch über den Dateinamen referenziert werden, indem ein zweites Argument an die Methode AntiSamy#scan() übergeben wird, wie die folgenden Beispiele zeigen:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
Schließlich können Policy-Dateien auch direkt als File-Objekte im zweiten Parameter referenziert werden:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
Das CleanResults-Objekt bietet eine Menge nützlicher Dinge.
getCleanHTML() – die bereinigte, sichere HTML-AusgabegetCleanXMLDocumentFragment() – das bereinigte, sichere XMLDocumentFragment, das in getCleanHTML() reflektiert wirdgetErrorMessages() – eine Liste von String-Fehlermeldungen – Wenn dies 0 zurückgibt, bedeutet das nicht, dass es keine Angriffe gab!getNumberOfErrors() – die Anzahl der Fehlermeldungen – Auch hier bedeutet 0 nicht, dass die Eingabe sicher war!getScanTime() – gibt die Scan-Zeit in Sekunden zurückWichtiger Hinweis: Es gab viel Verwirrung um die Methode getErrorMessages(). Die Methode getErrorMessages() (und auch nicht getNumberOfErrors()) beantwortet die Frage „Ist diese Eingabe sicher?“ nicht implizit mit Ja, wenn sie eine leere Liste zurückgibt. Sie müssen immer die bereinigte Eingabe verwenden, und es gibt keine Möglichkeit, sicher zu sein, dass die eingegebene Eingabe keine Angriffe enthielt.
Der Serialisierungs- und Deserialisierungsprozess, der für die Wirksamkeit des Sanitizers entscheidend ist, ist absichtlich verlustbehaftet und filtert Angriffe über eine Reihe von Angriffsvektoren heraus. Leider ist einer der Kompromisse dieser Strategie, dass AntiSamy im Nachhinein nicht immer weiß, dass ein Angriff gesehen wurde. Daher dienen die APIs getErrorMessages() und getNumberOfErrors() dazu, Benutzern zu helfen zu verstehen, ob ihre gut gemeinte Eingabe die Anforderungen des Systems erfüllt, und nicht einem Entwickler zu helfen, zu erkennen, ob ein Angriff vorlag.
Weitere Dokumentation ist auf der Wiki-Seite dieses GitHub-Projekts verfügbar: https://github.com/nahsra/antisamy/wiki und auf der OWASP AntiSamy Projektseite: https://owasp.org/www-project-antisamy/
Wenn Sie einen Fehler gefunden haben, erstellen Sie ein Issue im AntiSamy-Repository: https://github.com/nahsra/antisamy/issues
Wenn Sie eine Sicherheitslücke in AntiSamy gefunden haben, durchsuchen Sie zuerst die Issues-Liste (siehe oben), um festzustellen, ob sie bereits gemeldet wurde. Falls nicht, kontaktieren Sie bitte direkt Dave Wichers (dave.wichers at owasp.org). Bitte melden Sie Sicherheitslücken nicht über GitHub-Issues, da wir unsere Benutzer schützen möchten, während ein Patch implementiert und bereitgestellt wird. Wenn Sie für das Auffinden der Sicherheitslücke anerkannt werden möchten, befolgen Sie bitte diesen Prozess.
Weitere Details finden Sie in der Datei: SECURITY.md.
Sie können das Projekt ganz einfach aus dem Quellcode erstellen und testen:
$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package
Veröffentlicht unter der BSD-3-Clause-Lizenz, wie hier angegeben: LICENSE.