Non sono sicuro che il filter_xss di Drupal sia sicuro. Secondo il link che hai fornito, il filter_xss di Drupal si basa sulla libreria kses per il filtro HTML. Per dirla chiaramente, non mi fido dei filtri derivati da kses o kses.

Se osservi il codice di kses, si basa su una regexp mostruosa. È un'architettura scadente per un disinfettante HTML e non mi fido di nulla che sia stato costruito in quel modo. Se devi filtrare l'HTML arbitrario, il modo corretto per farlo è analizzare l'HTML e quindi operare sull'albero di analisi. (Il purificatore HTML funziona in questo modo, e in parte come risultato, mi fido molto di HTML Purifier.)

Storicamente, ks ha avuto alcuni problemi di sicurezza. Vedi, ad esempio, Vulnerabilità nei filtri HTML basati su ks e Sanificazione HTML: il diavolo nei dettagli (e le vulnerabilità) . Non so se tali vulnerabilità influiscano sulla versione di Drupal, ma non ispirano fiducia. Quindi, se avessi bisogno del filtro HTML, e se dovessi scegliere in base alla sicurezza, penso che probabilmente sceglierei HTML Purifier su filter_xss .

Dovrei anche fare un backup un po '. Non hai detto molto sulla situazione che stai affrontando. Sei sicuro che il filtro HTML sia lo strumento giusto per il tuo lavoro? Nella mia esperienza, è molto più comune che sia necessario l'escape HTML (codifica dell'output) piuttosto che il filtro HTML.

Se inserisci un input non affidabile in un documento HTML, devi decidere quale tipo di funzionalità ti serve:

• Fascicapo HTML, ovvero codifica dell'output. l'input fornito dall'utente è "solo testo normale", senza formattazione avanzata? In caso affermativo, utilizza l'escape HTML (noto anche come codifica dell'output), non filter_xss . Quando si esegue l'escape HTML, si desidera utilizzare l'escaping sensibile al contesto per sfuggire ai dati nel modo corretto per il contesto di analisi in cui verranno inseriti i dati non attendibili. Per saperne di più, leggi le seguenti risorse:

  • Le risorse di OWASP su XSS, tra cui la panoramica OWASP XSS e < a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet"> il foglio trucchi OWASP XSS Prevention . La libreria OWASP ESAPI ha funzioni di escape dell'output per tutti i contesti di analisi HTML in cui è probabile che si verifichi.

  • Filtra l'input dell'utente prima del database o sul display?

  • Riduzione di XSS tramite l'evasione automatica in base al contesto in Template Systems

• Filtro HTML. Vuoi consentire all'input fornito dall'utente di contenere una formattazione HTML avanzata? Vuoi consentire all'utente di inserire in HTML quasi arbitrario, che vuoi includere letteralmente nel documento di output? Se sì, hai bisogno di un filtro HTML. In questa situazione, HTML Purifier è una scelta eccellente e probabilmente più sicura di filter_xss di Drupal. Questa è solo la mia opinione personale.

Quando inserisco l'input fornito dall'utente in un documento HTML, la mia esperienza è probabilmente il 95% del tempo in cui desideri l'escape HTML, non il filtro HTML. Il filtro HTML è l'eccezione. (Quanto spesso ti aspetti che gli utenti inseriscano il markup HTML? Se stai scrivendo un'applicazione per la popolazione generale, la risposta è: quasi mai.) Quindi, sei sicuro di aver comunque bisogno di un filtro HTML?

D.W. ha alcuni punti eccellenti, ma vorrei solo sottolineare alcune cose:

This code does four things:

1. Removes characters and constructs that can trick browsers.
2. Makes sure all HTML entities are well-formed.
3. Makes sure all HTML tags and attributes are well-formed.
4. Makes sure no HTML tags contain URLs with a disallowed protocol (e.g. javascript:).

Supponendo che funzioni in modo eccellente su tutto questo elenco, ci sono alcune omissioni notevoli: bilanciamento tag , attacchi a livello di codifica , link spam .

Anche se lo fa bene, HTMLPurify è stato utilizzato ed è stato attaccato. Mi viene in mente almeno un accademico della sicurezza, che si assicura che HTMLPurify sia patchato e stabile prima di pubblicare nuovi attacchi. Se Drupal non riceve uno scrutinio simile, userei quello più duro.

Bilanciamento tag

Se la sicurezza dei tuoi utenti dipende dal fatto che siano in grado di distinguere il contenuto che hai creato da chi è stato autore di commentatori o di terze parti, il bilanciamento dei tag è importante.

Immagina di aver usato <table> s per la formattazione. I tag sbilanciati possono consentire loro di importare contenuti dalla regione che sembra essere contenuto di terze parti in un'area della pagina che sembra essere controllata dai proprietari del sito. Ad esempio, se la tua white-list includesse tag di formattazione altrimenti innocui come <table> , quindi

</table>
<center>If you have any questions,
<a href="[email protected]">contact us</a>
<br>Bogus copyright</center><br><br><br><br><sub><sub><sub><sub><sub>

potrebbe lasciare che l'attaccante forzi un piè di pagina che contiene collegamenti di phishing.

Un simile apparentemente innocuo </ul> potrebbe aiutare un utente malintenzionato a uscire da un elenco di commenti utente che vengono visualizzati utilizzando <ul><li>...</ul> per HTML semantico.

Le white-list configurabili dall'utente ti danno molto spazio per impiccarti qui dato che gli esperti HTML ritengono giustamente che elementi bilanciati come <table> e <ul> non facciano nulla di sensibile alla sicurezza (creano solo riquadri attorno al contenuto scorrevole) , ma i singoli tag sono problematici.

Attacchi a livello di codifica

Se l'autore dell'attacco può ottenere contenuto disinfettato nei primi kB di una pagina HTML che non ha un'intestazione Content-type che specifica una codifica, allora potrebbe essere in grado di indurre IE a trattare la pagina come UTF-7 , evitando tutte le altre condizioni igieniche.

Questo potrebbe rientrare in "costrutti che possono ingannare i browser", ma il codice sorgente su quella pagina non indica che lo faccia.

link spam

Se consenti i link ma il disinfettante non aggiunge rel="nofollow" ai link, la tua reputazione può essere dirottata.