What does a HTML filter need to do, to protect against SVG attacks?
I am one of the authors of this paper you linked. And I noticed, that some of the advice given in this thread is well-meant and well thought but not 100% correct.
For example, Opera is not providing reliable safety when dealing with SVGs embedded via <img> or CSS backgrounds. Here's an example for that, just for fun, we created a SVG embedded via <img> that would contain a PDF that would open a skype: URL that would then call you:
- http://heideri.ch/opera/
- http://www.slideshare.net/x00mario/the-image-that-called-me
We created the SVGPurifier - a set of rules that extend the HTMLPurifier to be able to deal with cleaning SVG. Back when we wrote those rules (you can have them if you want - let me know and I'll put 'em on Github), every browser we tested treated SVG differently. Also strongly dependent on the way it was embedded: inline, with <embed>/<object>, <applet>, <img>, SVG in SVG, CSS background, list-style and content...
It turned out that it was possible, to find a harmless subset in SVG if you threat model mainly involved XSS and beyond. If your threat model nevertheless also includes for instance mitigation of UI overlaps, side-channels, history stealing attacks and what not it gets a bit harder. Here's for example a funny snippet showing, how we can cause XSS with very much obfuscated JavaScript URI handlers: http://jsbin.com/uxadon
Then we have inline SVG. In my personal opinion, this was one of the worst ideas W3C/WHATWG ever had. Allowing XML documents inside HTML5 documents, forcing them to comply with HTML5 parsing rules and what not... security nightmare. Here's one gripping example of inline SVG and contained JavaScript that shows, what you'd be dealing with: http://pastebin.com/rmbiqZgd
To not have this whole thing end up in a long lament on how terrible SVG might be in a security/XSS context, here's some advice. If you really and still want to / are working on this HTML filter, consider doing the following:
Give us a public some-test where we can hammer that thing.
Be flexible with your rule-set, expect new bypasses every day.
Make sure to know what the implications of filtering inline SVG are.
Try to see if the HTMLPurifier approach might be the best. White-list, don't black-list.
Avoid reg-ex at all costs. This is not a place for regular expressions to be used.
Make sure that your subset only allows those elements, that have been tested for security problems in all relevant browsers. Remember the SVG key-logger? http://html5sec.org/#132
Study the SVG-based attacks that were already published and be prepared to find more on a regular basis: http://html5sec.org/?svg
I like the idea of someone attempting to build a properly maintained and maybe even working HTML+SVG filter and I'd be more than happy to test it - as many others as well I assume. But be aware: HTML filtering is damn hard already - and SVG just adds a whole new layer of difficulty to it.
As far as I know the following ways can be used to refer to an svg.
<img src="http://example.com/some-svg.svg">- Any tag with css styles. e.g.
style="background-image:url(http://example.com/some-svg.svg) - Filtering on extensions is not enough. HTTP headers determine the content type, not the extension. A
.jpgfile may be read as an SVG. Therefore, any remote image is dangerous. - You can inline any XML format, including SVG, in a web page.
Even if you check for all the items above, you cannot be sure that there is no SVG injection possible. You may want to go for white-listing instead of blacklisting.