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:
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
<img>, SVG in SVG, CSS
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.