Buona giornata!
Modifica: Ci scusiamo per i link non collegati - dato che ho appena creato il mio account per rispondere a questo non ho abbastanza "cred" per pubblicare più di 2 link per post ...
Questo post non è il più fresco che io consideri - ma risponderò comunque. Sono uno degli autori di questo articolo che hai linkato. E ho notato che alcuni dei consigli dati in questa discussione sono ben pensati e ben pensati ma non corretti al 100%.
Ad esempio, Opera non fornisce sicurezza affidabile quando si tratta di SVG incorporati tramite <img> o sfondi CSS. Ecco un esempio per questo, solo per i divertimenti abbiamo creato un SVG incorporato tramite <img> che conterrebbe un PDF che aprirebbe un skype: URL che poi ti chiamerebbe:
-
http://heideri.ch/opera/
-
http://www.slideshare.net/x00mario/the-image-that-called-me
Abbiamo creato SVGPurifier, un insieme di regole che estendono l'HTMLPurifier per poter gestire SVG di pulizia. Quando abbiamo scritto quelle regole (puoi averli se vuoi - fammelo sapere e li inserirò su Github), ogni browser che abbiamo testato ha trattato SVG in modo diverso. Anche strongmente dipendente dal modo in cui è stato incorporato: in linea, con <embed> / <object> , <applet> , <img> , SVG in SVG, CSS background , list-style e content ...
Si è scoperto che era possibile trovare un sottoinsieme innocuo in SVG se il modello di minaccia coinvolgeva principalmente XSS e oltre. Se il tuo modello di minaccia include anche, ad esempio, la mitigazione delle sovrapposizioni dell'interfaccia utente, i canali secondari, gli attacchi di furto della cronologia e cosa non diventa un po 'più difficile. Ecco ad esempio un frammento divertente che mostra come possiamo causare XSS con gestori di URI JavaScript offuscati: http://jsbin.com/uxadon
Quindi abbiamo SVG in linea. Secondo la mia opinione personale, questa è stata una delle peggiori idee che W3C / WHATWG abbia mai avuto. Permettere documenti XML all'interno di documenti HTML5, costringendoli a rispettare le regole di analisi HTML5 e cosa no ... incubo della sicurezza. Ecco un esempio avvincente di SVG in linea e contenuto JavaScript che mostra, con cosa avresti a che fare: http://pastebin.com/rmbiqZgd
Per non avere tutta questa faccenda finire in un lungo lamento su quanto possa essere terribile SVG in un contesto di sicurezza / XSS, ecco qualche consiglio. Se vuoi davvero continuare a lavorare su questo filtro HTML, considera quanto segue:
-
Dacci un po 'di pubblico in cui possiamo martellare quella cosa.
-
Sii flessibile con il tuo set di regole, aspettati nuovi bypass ogni giorno.
-
Assicurati di sapere quali sono le implicazioni del filtro di SVG in linea.
-
Prova a vedere se l'approccio HTMLPurifier potrebbe essere il migliore.
Lista bianca, non lista nera.
-
Evita il reg-ex a tutti i costi. Questo non è un posto per le espressioni regolari
da utilizzare.
-
Assicurati che il tuo sottoinsieme permetta solo quegli elementi, che sono stati
testato per problemi di sicurezza in tutti i browser pertinenti. Ricorda il
Registratore di tasti SVG? http://html5sec.org/#132
-
Studia gli attacchi basati su SVG che sono già stati pubblicati e preparati a trovarne altri regolarmente: http://html5sec.org/?svg
Mi piace l'idea che qualcuno tenti di costruire un filtro SVG HTML + correttamente gestito e magari funzionante e sarei più che felice di testarlo - come molti altri suppongo anch'io;) Ma attenzione: filtro HTML è già dannatamente difficile - e SVG aggiunge solo un nuovo livello di difficoltà.