Strumenti per sviluppatori · HTML WYSIWYG editor
Igienizzante incollato HTML: cosa rimuovere prima che raggiunga CMS o e-mail
· Come funziona
html sicurezza pulizia del testo
Spiega cosa fa un disinfettante HTML, dai tag e attributi consentiti agli script rimossi e agli URL neutralizzati, e in che modo il primo controllo del markup semplifica la scrittura delle regole di disinfettazione.
Lo snippet incollato che conteneva un onclick si apre con il rischio nascosto nell'input rich-text
Un'ancora incollata può nascondere un onclick accanto a una destinazione innocente. ToolAcre mette in minuscolo ogni nome di attributo e mantiene solo gli attributi esplicitamente elencati per l'elemento accettato, quindi onclick scompare anche quando la sua maiuscola viene modificata. Il report di rimozione identifica il gestore eventi invece di presentare silenziosamente l'origine invariata.
Questo limite opera prima dell'inserimento del Rich Paste, quando l'origine ritorna in modalità visiva, prima della copia, prima dell'estrazione del testo semplice e di nuovo durante la creazione di documenti di anteprima. La ripetizione riduce il bypass accidentale tra le azioni, ma il progetto rifiuta comunque di chiamare il tokenizzatore scritto a mano un filtro XSS di uso generale.
Perché le liste consentite battono le liste bloccate: spiega che nominare ciò che è consentito è più sicuro che cercare di elencare ogni costrutto pericoloso
Una lista consentita inizia nominando la struttura consentita: paragrafi, intestazioni, elementi semantici in linea, elenchi, elenchi di descrizioni, citazioni, elementi simili a codici e ancore. Un wrapper ordinario sconosciuto perde il tag pur conservando il testo. Anche un contenitore pericoloso come script, stile, iframe, modulo, SVG o MathML perde il suo contenuto.
Una lista di blocco dovrebbe anticipare ogni costruzione pericolosa o non supportata. La lista consentita rifiuta ciò che non capisce. Questa è una scelta forte per l’output limitato di un editor, ma rimane vincolato dal suo tokenizzatore. Il ripristino degli errori del browser HTML5 può produrre un albero diverso da un parser più piccolo quando è coinvolto un input deliberatamente non corretto.
Tag, attributi e schemi URL: copre i tre livelli di filtraggio di un disinfettante, con decisioni tipiche per ciascuno
Il filtraggio avviene su tre livelli. Gli elementi decidono il vocabolario strutturale. Gli attributi per elemento consentono solo pochi valori come link href e titolo, citazione di citazione, titolo di abbreviazione e inizio e tipo di elenco ordinato. L'ispezione URL decodifica quindi le entità, rimuove i controlli e gli spazi bianchi da un'analisi e controlla lo schema risultante.
Gli schemi accettati sono http, https, mailto, tel e ftp, più le relative forme senza schema esplicito. JavaScript, dati, file, blob, vbscript e esempi vengono rifiutati nei test. I collegamenti sopravvissuti acquisiscono valori rel, ma tale aggiunta non sostituisce la politica di destinazione o la revisione dei collegamenti.
Stili: elimina, consenti o riscrivi: illustra la gestione degli stili in linea e il motivo per cui molti sistemi lo eliminano completamente
Gli attributi di stile vengono rimossi completamente. Il modulo non tenta di analizzare dichiarazioni, conservare un sottoinsieme sicuro o riscrivere token di progettazione. Tale criterio rimuove l'aspetto copiato e le richieste basate su CSS visualizzate insieme. Anche gli attributi class, id e data scompaiono, producendo markup portabile ma deliberatamente meno espressivo.
I sistemi con un reale requisito di stile necessitano di una politica rivista diversa. L'aggiunta di stile a questa lista consentita senza un disinfettante CSS cambierebbe sostanzialmente la sua superficie di sicurezza. L'attuale implementazione evita questo problema invece di pretendere di risolvere la sicurezza CSS per frammenti ostili arbitrari.
Esempio funzionante: ricavare la regola dalla lista consentita documentata di ToolAcre, non da un dispositivo specifico di Word
Inizia con `<div class="WordSection"><p style="color:red" onclick="x()">Notice <strong>today</strong></p></div>`. Il div viene scartato, classe e stile non possono sopravvivere, onclick viene rimosso e rimangono il paragrafo più l'elemento strong. Il risultato segue una politica generica senza specificare quale applicazione ha prodotto il wrapper.
Aggiungi un href javascript e un blocco di script. L'ancora mantiene le sue parole visibili ma perde href; la sceneggiatura e il corpo scompaiono. Leggi le motivazioni riportate. Questo esercizio aiuta a definire una policy del server, ma la copia cieca del sottoinsieme esatto di ToolAcre può omettere elementi richiesti dall'applicazione o consentire URL vietati dal modello di minaccia.
Sanificazione lato server rispetto a quella lato client: spiega perché il server deve essere disinfettato anche se il browser lo ha già fatto
Il filtraggio del client migliora la redazione locale ma non può essere considerato attendibile da un server che riceve richieste controllate dall'utente. Gli aggressori possono bypassare la pagina, chiamare direttamente un endpoint o sfruttare una differenza del parser. Il server deve analizzare e disinfettare nuovamente con un'implementazione HTML5 mantenuta configurata per il relativo contesto di rendering.
Anche la codifica dell'output rimane separata. HTML inteso come testo deve essere sottoposto a escape dal modello anziché inserito come markup. Un frammento reso intenzionalmente come HTML necessita di pulizia prima dell'archiviazione o dell'output in base all'architettura. Un'anteprima in modalità sandbox dimostra solo che questa anteprima non garantisce script, moduli o accesso dalla stessa origine.
Ciò che copre questo strumento: filtraggio ristretto dell'output dell'editor, non pulizia generale degli input ostili
ToolAcre filtra la propria superficie di output, contrariamente a quanto affermato nella cartella di lavoro secondo cui si tratta semplicemente di uno strumento di ispezione. La correzione accurata è più ristretta: non è un disinfettante XSS generico per input ostili arbitrari. La fonte lo dice esplicitamente e documenta un possibile differenziale del parser.
L'iframe è una difesa approfondita per il rendering all'interno di ToolAcre. Il suo attributo sandbox vuoto non garantisce l'esecuzione di script, l'invio di moduli o l'accesso alla stessa origine e la politica di riferimento è no-referrer. Una volta che HTML viene copiato altrove, quel frame non lo protegge più. La sicurezza della pubblicazione appartiene al sistema ricevente.
Conclusione: ispeziona localmente, disinfetta sul server: riassume il flusso di lavoro e il modo in cui l'editor ti aiuta a vedere cosa dovrà affrontare un disinfettante
Ispeziona localmente, disinfetta il server ed esegue il rendering in base al contesto. Si tratta di tre passaggi distinti. ToolAcre aiuta a rivelare i bagagli incollati e offre un sottoinsieme di bozze conservativo, mentre gli avvisi di rimozione rendono visibili gli effetti delle policy prima che un frammento raggiunga un CMS o un flusso di lavoro via email.
Non commercializzare un'anteprima riuscita come prova contro XSS. Utilizza i payload di test solo in contenuti usa e getta, conserva la fonte grezza separatamente quando l'indagine è importante e verifica la sanificazione della destinazione in modo indipendente. Le richieste di sicurezza dovrebbero terminare esattamente dove si fermano il codice e il limite di rendering.