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:
StringFileInputStreamPolicy possono anche essere referenziati per nome file passando un secondo argomento al metodo AntiSamy#scan() come mostrano i seguenti esempi:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
Infine, i file di policy possono anche essere referenziati tramite oggetti File direttamente nel secondo parametro:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
L'oggetto CleanResults fornisce un sacco di cose utili.
getErrorMessages() - una lista di messaggi di errore String -- se restituisce 0 ciò non significa che non ci sono stati attacchi!getCleanHTML() - l'output HTML pulito e sicurogetCleanXMLDocumentFragment() - il XMLDocumentFragment pulito e sicuro che si riflette in getCleanHTML()getScanTime() - restituisce il tempo di scansione in secondiNota importante: C'è stata molta confusione sul metodo getErrorMessages(). Il metodo getErrorMessages() non risponde sottilmente alla domanda "questo input è sicuro?" in modo affermativo se restituisce una lista vuota. Devi sempre usare l'input sanitizzato e non c'è modo di essere sicuri che l'input passato non contenesse attacchi.
Il processo di serializzazione e deserializzazione che è critico per l'efficacia del sanitizer è intenzionalmente lossy (con perdita di dati) e filtrerà gli attacchi tramite una serie di vettori d'attacco. Sfortunatamente, uno dei compromessi di questa strategia è che non sempre sappiamo a posteriori che un attacco è stato visto. Pertanto, l'API getErrorMessages() serve ad aiutare gli utenti a capire come il loro input ben intenzionato soddisfi i requisiti del sistema, non ad aiutare uno sviluppatore a rilevare se un attacco era presente.
Documentazione aggiuntiva è disponibile sulla pagina wiki di questo progetto Github: https://github.com/nahsra/antisamy/wiki e sulla Pagina del Progetto OWASP AntiSamy: https://owasp.org/www-project-antisamy/
Se hai trovato un bug, crea un problema (issue) nel repository di AntiSamy: https://github.com/nahsra/antisamy/issues
Se hai trovato una vulnerabilità in AntiSamy, prima cerca nella lista dei problemi (vedi sopra) per vedere se è già stata segnalata. Se non lo è, contatta direttamente Dave Wichers (dave.wichers at owasp.org). Per favore non segnalare vulnerabilità tramite gli issue di GitHub poiché desideriamo mantenere i nostri utenti al sicuro mentre una patch viene implementata e distribuita. Se desideri essere riconosciuto per aver trovato la vulnerabilità, segui questo processo.
Maggiori dettagli sono disponibili nel file: SECURITY.md.
Puoi compilare e testare dal sorgente abbastanza facilmente:
$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package
Rilasciato sotto la licenza BSD-3-Clause come specificato qui: LICENSE.