shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1Java-Bibliothek für schnelle, konfigurierbare Bereinigung von nicht vertrauenswürdigem HTML, um Cross-Site-Scripting-Angriffe (XSS) zu verhindern. Verwendet richtlinienbasiertes Scannen, um vom Benutzer bereitgestelltes Markup zu bereinigen.
Eine Bibliothek zur schnellen, konfigurierbaren Bereinigung von HTML aus nicht vertrauenswürdigen Quellen. Unterstützt Java 7+.
Eine andere Art, das zu sagen, wäre: Es ist eine API, die Ihnen hilft sicherzustellen, dass Clients keinen bösartigen Frachtcode in das HTML einfügen, das sie für ihr Profil, Kommentare usw. bereitstellen und das auf dem Server gespeichert wird. Der Begriff „bösartiger Code" bezieht sich bei Webanwendungen meist auf „JavaScript". Meistens gelten Cascading Stylesheets nur dann als bösartig, wenn sie JavaScript aufrufen. Es gibt jedoch viele Situationen, in denen „normales" HTML und CSS auf bösartige Weise verwendet werden können.
Fügen Sie zunächst die Abhängigkeit von Maven hinzu:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
Es ist wahrscheinlich, dass der Anwendungsfall Ihrer Website für AntiSamy zumindest grob mit einer der vordefinierten Policy-Dateien vergleichbar ist. Jede davon repräsentiert ein „typisches" Szenario für die Erlaubnis, dass Benutzer HTML- (und möglicherweise CSS-) Formatierungsinformationen bereitstellen. Schauen wir uns die verschiedenen Policy-Dateien an:
Slashdot ist eine Technik-Nachrichtenseite, die es Benutzern erlaubt, anonym mit sehr begrenztem HTML-Markup auf Nachrichtenbeiträge 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 eine ziemlich ähnliche Funktionalität ermöglicht. Alle Textformatierungs-Tags, die direkt auf Schriftart, Farbe oder Hervorhebung wirken, wurden erlaubt.
eBay ist, soweit ich das beurteilen kann, die beliebteste Online-Auktionsseite im Universum. Es ist eine öffentliche Website, auf der jeder Einträge mit reichhaltigem HTML-Inhalt veröffentlichen darf. Es ist nicht überraschend, dass eBay aufgrund seiner Attraktivität als Angriffsziel einigen komplexen XSS-Angriffen ausgesetzt war. Einträge dürfen wesentlich reichhaltigere Inhalte enthalten als beispielsweise Slashdot – daher ist die Angriffsfläche erheblich größer.
MySpace war zu der Zeit, als dieses Projekt entstand, die beliebteste soziale Netzwerk-Website. 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 zur Validierung des Benutzer-HTML, weshalb es dem berüchtigten Samy-Wurm ausgesetzt war. Der Samy-Wurm, der Fragmentierungsangriffe in Kombination mit einem Wort verwendete, das hätte auf der Blacklist stehen sollen (eval), war die Inspiration für dieses Projekt.
Ich kenne keinen möglichen Anwendungsfall für diese Policy-Datei. Wenn Sie jedes einzelne gültige HTML- und CSS-Element erlauben möchten (aber ohne JavaScript oder offensichtliche CSS-bezogene 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.
Während wir an Verbesserungen an der XML-Schema-Definition (XSD) von AntiSamy für AntiSamy-Policy-Dateien arbeiteten, stellten wir fest, dass AntiSamy die XSD tatsächlich NICHT durchsetzte. Daher haben wir das Standardverhalten ab AntiSamy 1.6.0 GEÄNDERT, um das Schema durchzusetzen und nicht fortzufahren, wenn die AntiSamy-Policy ungültig ist. Allerdings ...
Wir erkennen an, dass es für Entwickler möglicherweise nicht sofort möglich ist, ihre AntiSamy-Policies zu korrigieren, wenn sie nicht konform sind, und sie dennoch AntiSamy aktualisieren möchten, um Sicherheitsverbesserungen, Funktionserweiterungen und Fehlerbehebungen zu erhalten. Daher haben wir zwei Möglichkeiten bereitgestellt, die Schema-Validierung (vorübergehend!) zu deaktivieren:
Setzen Sie die Java-Systemeigenschaft: owasp.validator.validateschema auf false. Dies kann über die Befehlszeile erfolgen (z. B. -Dowasp.validator.validateschema=false) oder über die Java-Systemeigenschaftendatei. Keines davon erfordert eine Codeänderung.
Ändern Sie den Code, der AntiSamy verwendet, um vor dem Laden der AntiSamy-Policy Folgendes aufzurufen: Policy.setSchemaValidation(false). Dies ist ein statischer Aufruf. Sobald er deaktiviert ist, ist er für alle neuen Policy-Instanzen deaktiviert.
Um AntiSamy-Benutzer zu ermutigen, nur XSD-konforme Policies zu verwenden, protokolliert AntiSamy immer eine Art Warnung, wenn die Schema-Validierung deaktiviert ist. Es wird entweder WARNEN, dass die Policy nicht konform ist, damit sie behoben werden kann, oder es wird WARNEN, dass die Policy konform ist, aber die Schema-Validierung AUS ist, sodass die Validierung wieder aktiviert werden sollte (d. h. nicht weiter deaktiviert werden sollte). Wir haben außerdem INFO-Level-Protokollierung hinzugefügt, wenn AntiSamy-Schemas geladen und validiert werden.
Die Möglichkeit, die neue Schema-Validierungsfunktion zu deaktivieren, ist als vorübergehend gedacht, um den Übergang zu ordnungsgemäß gültigen AntiSamy-Policy-Dateien zu erleichtern. Wir planen, diese Funktion in der nächsten großen Version zu entfernen. Wir schätzen, dass dies irgendwann Mitte bis Ende 2022 sein wird, also nicht in nächster Zeit. Die Idee ist, Entwicklerteams, die AntiSamy direkt oder über andere Bibliotheken wie ESAPI verwenden, ausreichend Zeit zu geben, ihre Policy-Dateien schema-konform zu machen, bevor die Schema-Validierung erforderlich wird.
Dies wurde in 1.6.1 schnell behoben, sodass nur noch slf4j-APIs verwendet werden. AntiSamy enthält jetzt die Bibliothek slf4j-simple für seine Protokollierung, aber AntiSamy-Benutzer können eine alternative slf4j-kompatible Protokollierungsbibliothek importieren und verwenden, wenn sie dies bevorzugen. 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 Protokollmeldungen verloren gehen, wenn eine Ausnahme wie eine PolicyException ausgelöst wird. Dies kann wahrscheinlich behoben werden, indem slf4j-simple so konfiguriert wird, dass es stattdessen auf die Standardfehlerausgabe protokolliert, oder indem ein alternatives slf4j-Logger verwendet wird, der dies tut.
Möglicherweise möchten Sie AntiSamy in einer Standardkonfiguration bereitstellen, aber es ist ebenso wahrscheinlich, dass eine Website strenge, geschäftsgetriebene Regeln dafür haben möchte, was Benutzer erlauben dürfen. Die Diskussion, die die Anpassung bestimmt, sollte auch die Angriffsfläche berücksichtigen – die im relativen Verhältnis zur Policy-Datei wächst.
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 mehrere Möglichkeiten, ein Policy-Objekt zu erstellen. Die Methode getInstance() kann eines der folgenden Argumente akzeptieren:
String-DateinamenFile-ObjektInputStreamPolicy-Dateien können auch per 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 über 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.
getErrorMessages() - eine Liste von String-Fehlermeldungen -- wenn dies 0 zurückgibt, bedeutet das nicht, dass es keine Angriffe gab!getCleanHTML() - die bereinigte, sichere HTML-AusgabegetCleanXMLDocumentFragment() - das bereinigte, sichere XMLDocumentFragment, das sich in getCleanHTML() widerspiegeltgetScanTime() - gibt die Scanzeit in Sekunden zurückWichtiger Hinweis: Es gab viel Verwirrung über die Methode getErrorMessages(). Die Methode getErrorMessages() beantwortet nicht subtil die Frage „Ist diese Eingabe sicher?" im Affirmativ, 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 übergebene 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 wir im Nachhinein nicht immer wissen, dass ein Angriff gesehen wurde. Daher existiert die getErrorMessages()-API, um Benutzern zu helfen zu verstehen, wie ihre gut gemeinte Eingabe die Anforderungen des Systems erfüllt, und nicht, um einem Entwickler zu helfen, zu erkennen, ob ein Angriff vorhanden war.
Weitere Dokumentation ist auf der Wiki-Seite dieses Github-Projekts verfügbar: https://github.com/nahsra/antisamy/wiki sowie auf der OWASP AntiSamy-Projektseite: https://owasp.org/www-project-antisamy/
Wenn Sie einen Fehler gefunden haben, erstellen Sie ein Issue im AntiSamy-Repo: https://github.com/nahsra/antisamy/issues
Wenn Sie eine Schwachstelle in AntiSamy gefunden haben, durchsuchen Sie zunächst die Issue-Liste (siehe oben), um festzustellen, ob sie bereits gemeldet wurde. Ist dies nicht der Fall, kontaktieren Sie bitte direkt Dave Wichers (dave.wichers at owasp.org). Bitte melden Sie Schwachstellen nicht über GitHub-Issues, da wir unsere Benutzer während der Implementierung und Bereitstellung eines Patches schützen möchten. Wenn Sie für das Finden der Schwachstelle anerkannt werden möchten, folgen Sie bitte diesem Prozess.
Weitere Details finden Sie in der Datei: SECURITY.md.
Sie können aus dem Quellcode ganz einfach bauen 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.