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