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.