¡Buen día!
Edit: Lo siento por los enlaces no vinculados, dado que acabo de crear mi cuenta para responder a esto, no tengo suficiente "cred" para publicar más de 2 enlaces por publicar ...
Esta publicación no es la más reciente, pero sí la responderé. Soy uno de los autores de este artículo que has vinculado. Y me di cuenta de que algunos de los consejos dados en este hilo están bien intencionados y bien pensados, pero no son 100% correctos.
Por ejemplo, Opera no proporciona seguridad confiable cuando se trata de SVG incrustados a través de <img> o fondos CSS. Aquí hay un ejemplo para eso, solo por las funciones que creamos un SVG incrustado a través de <img> que contendría un PDF que abriría una URL skype: que luego te llamaría:
-
http://heideri.ch/opera/
-
http://www.slideshare.net/x00mario/the-image-that-called-me
Creamos el SVGPurifier, un conjunto de reglas que extienden el HTMLPurifier para poder lidiar con la limpieza de SVG. Cuando escribimos esas reglas (puedes tenerlas si quieres, házmelo saber y las pondré en Github), cada navegador que probamos trataba a SVG de manera diferente. También depende en gran medida de la forma en que estaba incrustado: en línea, con <embed> / <object> , <applet> , <img> , SVG en SVG, CSS background , list-style y content ...
Resultó que era posible encontrar un subconjunto inofensivo en SVG si el modelo de amenaza involucraba principalmente a XSS y más allá. Sin embargo, si su modelo de amenaza también incluye, por ejemplo, la mitigación de las superposiciones de la interfaz de usuario, los canales laterales, los ataques de robo de historial y lo que no se vuelve un poco más difícil. Aquí hay, por ejemplo, un fragmento divertido que muestra cómo podemos causar XSS con controladores URI de JavaScript muy ofuscados: http://jsbin.com/uxadon
Entonces tenemos SVG en línea. En mi opinión personal, esta fue una de las peores ideas que W3C / WHATWG tuvo alguna vez. Permitir documentos XML dentro de documentos HTML5, obligándolos a cumplir con las reglas de análisis de HTML5 y qué no ... pesadilla de seguridad. Aquí hay un ejemplo fascinante de SVG en línea y JavaScript contenido que muestra, con lo que estarías tratando: http://pastebin.com/rmbiqZgd
Para que todo esto no termine en un largo lamento sobre lo terrible que podría ser SVG en un contexto de seguridad / XSS, aquí hay algunos consejos. Si realmente desea y está trabajando en este filtro HTML, considere hacer lo siguiente:
-
Danos un poco de prueba pública donde podamos martillar esa cosa.
-
Sea flexible con su conjunto de reglas, espere nuevos bypass todos los días.
-
Asegúrese de saber cuáles son las implicaciones del filtrado de SVG en línea.
-
Intente ver si el enfoque de HTMLPurifier podría ser el mejor.
Lista blanca, no lista negra.
-
Evite reg-ex a toda costa. Este no es un lugar para expresiones regulares.
para ser utilizado.
-
Asegúrese de que su subconjunto solo permita aquellos elementos que han sido
Probado para problemas de seguridad en todos los navegadores relevantes. Recuerda el
SVG key-logger? http://html5sec.org/#132
-
Estudie los ataques basados en SVG que ya se publicaron y prepárese para encontrar más en forma regular: http://html5sec.org/?svg
Me gusta la idea de que alguien intente construir un filtro SVG + HTML que esté bien mantenido e incluso funcione, y me encantaría probarlo, como muchos otros, supongo;) Pero tenga en cuenta: el filtrado de HTML ya es muy difícil, y SVG solo le agrega una nueva capa de dificultad.