shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1Libreria Java per la pulizia rapida e configurabile di HTML non attendibile per prevenire attacchi di cross-site scripting (XSS). Usa la scansione basata su policy per sanificare il markup fornito dall'utente.
Una libreria per eseguire una pulizia rapida e configurabile dell'HTML proveniente da fonti non attendibili. Supporta Java 7+.
Un altro modo per dirlo potrebbe essere: è un'API che ti aiuta a garantire che i client non forniscano codice dannoso nascosto nell'HTML che forniscono per il loro profilo, commenti, ecc., che viene persistito sul server. Il termine "codice dannoso" in relazione alle applicazioni web di solito significa "JavaScript". Per lo più, i Fogli di Stile a Cascata sono considerati dannosi solo quando invocano JavaScript. Tuttavia, ci sono molte situazioni in cui HTML e CSS "normali" possono essere usati in modo dannoso.
Per prima cosa, aggiungi la dipendenza da Maven:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
È probabile che il caso d'uso del tuo sito per AntiSamy sia almeno approssimativamente paragonabile a uno dei file di policy predefiniti. Ciascuno di essi rappresenta uno scenario "tipico" per consentire agli utenti di fornire informazioni di formattazione HTML (e possibilmente CSS). Diamo un'occhiata ai diversi file di policy:
Slashdot è un sito di news tecnologiche che consente agli utenti di rispondere in modo anonimo ai post con markup HTML molto limitato. Ora, Slashdot non è solo uno dei siti più interessanti in circolazione, ma è anche uno che è stato soggetto a molti attacchi riusciti. Le regole per Slashdot sono abbastanza rigide: gli utenti possono inviare solo i seguenti tag HTML e nessun CSS: <b>, <u>, <i>, <a>, <blockquote>.
Di conseguenza, abbiamo creato un file di policy che consente funzionalità abbastanza simili. Tutti i tag di formattazione del testo che operano direttamente su font, colore o enfasi sono stati consentiti.
eBay è il sito di aste online più popolare dell'universo, per quanto posso dire. È un sito pubblico, quindi chiunque può pubblicare annunci con contenuti HTML ricchi. Non sorprende che, data l'attrattiva di eBay come obiettivo, sia stato soggetto ad alcuni complessi attacchi XSS. Gli annunci possono contenere contenuti molto più ricchi di, ad esempio, Slashdot -- quindi la sua superficie d'attacco è considerevolmente più ampia.
MySpace era, al momento della nascita di questo progetto, il sito di social networking più popolare. Agli utenti era consentito inviare praticamente tutto l'HTML e il CSS che volevano -- purché non contenesse JavaScript. MySpace usava una blacklist di parole per validare l'HTML degli utenti, motivo per cui è stato soggetto al famigerato worm Samy. Il worm Samy, che utilizzava attacchi di frammentazione combinati con una parola che avrebbe dovuto essere in blacklist (eval) -- è stato l'ispirazione per questo progetto.
Non conosco un possibile caso d'uso per questo file di policy. Se vuoi consentire ogni singolo elemento HTML e CSS valido (ma senza JavaScript o attacchi di phishing palesi legati al CSS), puoi usare questo file di policy. Nemmeno MySpace era così folle. Tuttavia, serve come buon riferimento perché contiene regole di base per ogni elemento, quindi puoi usarlo come base di conoscenza quando adatti gli altri file di policy.
Mentre lavoravamo ad alcuni miglioramenti alla Definizione dello Schema XML (XSD) di AntiSamy per i file di policy di AntiSamy, abbiamo notato che AntiSamy non stava effettivamente applicando l'XSD. Quindi, abbiamo CAMBIATO il comportamento predefinito a partire da AntiSamy 1.6.0 per applicare lo schema e non continuare se la policy di AntiSamy non è valida. Tuttavia ...
riconosciamo che potrebbe non essere possibile per gli sviluppatori correggere subito le loro policy di AntiSamy se non sono conformi, e tuttavia voler aggiornare AntiSamy per ottenere miglioramenti della sicurezza, nuove funzionalità e correzioni di bug. A tal fine, abbiamo fornito due modi per disabilitare (temporaneamente!) la validazione dello schema:
Impostare la proprietà di sistema Java: owasp.validator.validateschema su false. Questo può essere fatto dalla riga di comando (ad esempio, -Dowasp.validator.validateschema=false) o tramite il file delle proprietà di sistema Java. Nessuno dei due richiede una modifica al codice.
Modificare il codice che usa AntiSamy per invocare: Policy.setSchemaValidation(false) prima di caricare la policy di AntiSamy. Questa è una chiamata statica, quindi una volta disabilitata, rimane disabilitata per tutte le nuove istanze di Policy.
Per incoraggiare gli utenti di AntiSamy a utilizzare solo policy conformi all'XSD, AntiSamy registrerà sempre qualche tipo di avviso quando la validazione dello schema è disabilitata. O avviserà (WARN) che la policy non è conforme così può essere corretta, oppure avviserà (WARN) che la policy è conforme, ma la validazione dello schema è DISATTIVATA, quindi la validazione dovrebbe essere riattivata (cioè smettere di disabilitarla). Abbiamo anche aggiunto la registrazione a livello INFO quando gli schemi di AntiSamy vengono caricati e validati.
La possibilità di disabilitare la nuova funzionalità di validazione dello schema è intesa come temporanea, per agevolare la transizione a file di policy AntiSamy correttamente validi. Prevediamo di eliminare questa funzionalità nella prossima versione principale. Stimiamo che ciò avverrà tra metà e fine 2022, quindi non così presto. L'idea è dare ai team di sviluppo che usano AntiSamy direttamente, o tramite altre librerie come ESAPI, tutto il tempo necessario per rendere i loro file di policy conformi allo schema prima che la validazione dello schema diventi obbligatoria.
Questo è stato rapidamente corretto nella 1.6.1 per usare solo le API slf4j. AntiSamy ora include la libreria slf4j-simple per la sua registrazione, ma gli utenti di AntiSamy possono importare e usare una libreria di registrazione alternativa compatibile con slf4j se preferiscono. Possono anche escludere slf4j-simple se lo desiderano.
ATTENZIONE: L'uso di slf4j-simple da parte di AntiSamy, senza alcun file di configurazione, registra i messaggi in modo bufferizzato sullo standard output. Di conseguenza, alcuni o tutti questi messaggi di registro potrebbero andare persi se viene lanciata un'eccezione, come una PolicyException. Questo può probabilmente essere risolto configurando slf4j-simple per registrare sullo standard error, oppure usando un logger slf4j alternativo che lo faccia.
Potresti voler implementare AntiSamy in una configurazione predefinita, ma è altrettanto probabile che un sito voglia avere regole rigide, guidate dal business, su ciò che gli utenti possono consentire. La discussione che determina l'adattamento dovrebbe anche considerare la superficie d'attacco - che cresce in proporzione relativa al file di policy.
Usare AntiSamy è facile. Ecco un esempio di invocazione di AntiSamy con un file di policy:
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
Ci sono alcuni modi per creare un oggetto Policy. Il metodo getInstance() può accettare uno qualsiasi dei seguenti: