shoucheng3/nahsra__antisamy_cve-2017-14735_1-5-6Libreria Java per una sanificazione HTML veloce e configurabile da fonti non fidate. Utilizza una scansione basata su policy per rimuovere JavaScript e CSS dannosi, prevenendo attacchi XSS nelle applicazioni web.
Una libreria per eseguire una pulizia veloce e configurabile di HTML proveniente da fonti non affidabili. Supporta Java 8+.
Un altro modo per dirlo potrebbe essere: è un'API che ti aiuta a garantire che i client non forniscano codice malevolo (malicious cargo code) nell'HTML che forniscono per il loro profilo, commenti, ecc., che viene poi persistito sul server. Il termine "codice malevolo" in ambito applicazioni web di solito significa "JavaScript". Per lo più, i Cascading Stylesheets sono considerati malevoli solo quando invocano JavaScript. Tuttavia, ci sono molte situazioni in cui HTML e CSS "normali" possono essere usati in modo malevolo.
Durante lo sviluppo della serie 1.6.x, abbiamo identificato e deprecato diverse funzionalità e API. Tutti questi elementi deprecati sono stati rimossi nella release 1.7.0. Queste modifiche sono state tutte tracciate nel ticket: https://github.com/nahsra/antisamy/issues/195. Ogni modifica è descritta di seguito:
CssHandler aveva 2 costruttori che eliminavano il parametro LinkedList<URI> embeddedStyleSheets. Entrambi i costruttori ora creano un LinkedList<URI> interno vuoto e il metodo getImportedStylesheetsURIList() può essere utilizzato per ottenere un riferimento ad esso, se necessario. Questa funzionalità è usata raramente, e di fatto anche l'invocazione diretta di questi costruttori è rara, quindi questa modifica difficilmente influenzerà la maggior parte degli utenti di AntiSamy. Quando usata, normalmente viene passata una lista vuota come valore di questo parametro e quella lista non viene mai più utilizzata.
La firma CssHandler(Policy, LinkedList<URI>, List<String>, ResourceBundle) è stata rimossa
CssHandler(Policy, List<String>, ResourceBundle)La firma CssHandler(Policy, LinkedList<URI>, List<String>, String, ResourceBundle) è stata rimossa
CssHandler(Policy, List<String>, ResourceBundle, String). NOTA: L'ordine degli ultimi 2 parametri di questo metodo è stato invertito.Il supporto per XHTML è stato rimosso. AntiSamy ora supporta solo HTML. Poiché riteniamo che questa fosse una funzionalità usata raramente, non ci aspettiamo che ciò influenzi molti utenti di AntiSamy.
La validazione dello schema XML è ora obbligatoria sui file di policy di AntiSamy e non può essere disabilitata. Devi rendere il tuo file di policy conforme allo schema per poterlo utilizzare con AntiSamy.
La direttiva di policy noopenerAndNoreferrerAnchors è ora ATTIVA per impostazione predefinita. Se viene disabilitata, AntiSamy emette un avviso (nag) incoraggiandoti ad abilitarla.
Nel ciclo di vita degli aggiornamenti di AntiSamy, la dipendenza dal parser HTML ha subito modifiche, portando ad alcune differenze nell'output che possono emergere a seconda del caso d'uso. Tienilo in considerazione se stavi usando determinate versioni e ottieni output diversi dopo l'aggiornamento.
Questo può valere anche per il serializzatore di output che trasforma la rappresentazione HTML interna nell'output testuale finale dello strumento.
Il team di AntiSamy ha deciso che supportare la possibilità di consentire CSS remoti incorporati è pericoloso e quindi stiamo deprecando questa funzionalità, che sarà rimossa in una release futura. Si prevede che ci siano pochissimi, se non nessuno, utenti di questa funzionalità.
Abbiamo aggiunto un log WARNing se questa funzionalità viene invocata. Se lo stai facendo, disabilita/rimuovi questa funzionalità passando al costruttore primario CssScanner che non abilita questa funzionalità.
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 simile a uno dei file di policy predefiniti. Ognuno rappresenta uno scenario "tipico" per consentire agli utenti di fornire formattazione HTML (e possibilmente CSS). Diamo un'occhiata ai diversi file di policy:
Slashdot è un sito di notizie tecnologiche che permette agli utenti di rispondere anonimamente ai post con markup HTML molto limitato. Ora, Slashdot non solo è uno dei siti più interessanti in circolazione, ma è anche uno che è stato oggetto di molti attacchi riusciti diversi. Le regole per Slashdot sono piuttosto rigide: gli utenti possono inviare solo i seguenti tag HTML e nessun CSS: <b>, <u>, <i>, <a>, <blockquote>.
Di conseguenza, abbiamo costruito un file di policy che consente funzionalità abbastanza simili. Sono stati permessi tutti i tag di formattazione del testo che agiscono direttamente sul font, colore o enfasi.
eBay è il sito di aste online più popolare dell'universo, per quanto ne sappiamo. È un sito pubblico, quindi chiunque può pubblicare inserzioni con contenuti HTML ricchi. Non sorprende che, data l'attrattività di eBay come bersaglio, sia stato soggetto a diversi attacchi XSS complessi. Le inserzioni possono contenere contenuti molto più ricchi rispetto, ad esempio, a Slashdot – quindi la sua superficie d'attacco è considerevolmente maggiore.
MySpace era, al momento della nascita di questo progetto, il sito di social networking più popolare. Agli utenti era permesso inviare praticamente tutto l'HTML e CSS che volevano – purché non contenesse JavaScript. MySpace utilizzava una blacklist di parole per validare l'HTML degli utenti, motivo per cui fu soggetto al famigerato worm Samy. Il worm Samy, che utilizzava attacchi di frammentazione combinati con una parola che avrebbe dovuto essere nella blacklist (eval), è stato l'ispirazione per questo progetto.
Non conosciamo un possibile caso d'uso per questo file di policy. Se desideri consentire ogni singolo elemento HTML e CSS valido (ma senza JavaScript o evidenti attacchi di phishing basati su CSS), puoi usare questo file di policy. Nemmeno MySpace era così folle. Tuttavia, funge da buon riferimento perché contiene regole di base per ogni elemento, quindi puoi usarlo come base di conoscenza quando personalizzi gli altri file di policy.
AntiSamy ora include la libreria slf4j-simple per il suo logging, ma gli utenti di AntiSamy possono importare e utilizzare una libreria di logging 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 log potrebbero andare persi se viene lanciata un'Exception, come ad esempio una PolicyException. Questo può probabilmente essere risolto configurando slf4j-simple per registrare sullo standard error, oppure utilizzando un logger slf4j alternativo che lo faccia.
Potresti voler distribuire AntiSamy con una configurazione predefinita, ma è altrettanto probabile che un sito voglia avere regole rigide e guidate dal business per ciò che gli utenti possono consentire. La discussione che decide la personalizzazione dovrebbe anche considerare la superficie d'attacco – che cresce in proporzione relativa al file di policy.
Le policy di esempio possono essere adattate e testate in base ai requisiti per ogni tag. Le azioni supportate per i tag che possono essere specificate sono:
filter: rimuovi i tag, ma mantieni il contenuto.validate: mantieni il contenuto purché superi le regole.remove: rimuovi il tag e il contenuto.truncate: rimuovi gli attributi del tag e tutti i tag figli tranne il suo contenuto testuale, se presente.encode: simile a filter, ma codifica il tag per l'HTML per preservarlo come testo grezzo e i suoi figli vengono spostati di un livello superiore nella gerarchia.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()); // qualche funzione personalizzata
Ci sono diversi modi per creare un oggetto Policy. Il metodo getInstance() può accettare uno dei seguenti:
String nome fileFileInputStreamPolicy possono anche essere referenziati per nome file passando un secondo argomento al metodo AntiSamy#scan() come mostrato negli esempi seguenti:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
Infine, i file di policy possono anche essere referenziati direttamente da oggetti File nel secondo parametro:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
L'oggetto CleanResults fornisce molte cose utili.
getCleanHTML() - l'output HTML pulito e sicurogetCleanXMLDocumentFragment() - il XMLDocumentFragment pulito e sicuro che si riflette in getCleanHTML()getErrorMessages() - una lista di messaggi di errore di tipo String -- se restituisce 0, non significa che non ci siano stati attacchi!getNumberOfErrors() - il numero di messaggi di errore -- Ancora, 0 non significa che l'input fosse sicuro!getScanTime() - restituisce il tempo di scansione in secondiNota importante: C'è stata molta confusione riguardo al metodo getErrorMessages(). Il metodo getErrorMessages() (né getNumberOfErrors()) non risponde in modo sottile alla domanda "questo input è sicuro?" in modo affermativo se restituisce una lista vuota. Devi sempre usare l'input sanificato e non c'è modo di essere sicuri che l'input passato non avesse attacchi.
Il processo di serializzazione e deserializzazione che è fondamentale per l'efficacia del sanificatore è volutamente lossy (con perdita di informazioni) e filtrerà gli attacchi attraverso una serie di vettori di attacco. Sfortunatamente, uno dei compromessi di questa strategia è che AntiSamy non sempre sa retrospettivamente se un attacco è stato visto. Pertanto, le API getErrorMessages() e getNumberOfErrors() sono lì per aiutare gli utenti a capire se il loro input ben intenzionato soddisfa i requisiti del sistema, non per 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 issue nel repository di AntiSamy: https://github.com/nahsra/antisamy/issues
Se hai trovato una vulnerabilità in AntiSamy, controlla prima la lista degli issue (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é vogliamo mantenere i nostri utenti al sicuro mentre viene implementata e distribuita una patch. Se desideri essere riconosciuto per aver trovato la vulnerabilità, segui questa procedura.
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.