3 ms·

> Well, it's not really a thing. In a browser (the only kind of UA that'll really run any scripts in an SVG), SVG basically gets treated as SGML, all the DOM st

by sebcat 9y ago

> Well, it's not really a thing. In a browser (the only kind of UA that'll really run any scripts in an SVG), SVG basically gets treated as SGML, all the DOM stuff is the same. If you include it as an image tag, the scripts don't tend to run, AFAIK It breaks expectations. I havn't looked at it recently, but it used to be the case that hosting user submitted SVGs on your domain could yield JS-execution in the origin context. Embedding or iframing without sandbox isn't/wasn't secure either. A quick google search on SVG XSS gives: https://hackerone.com/reports/148853 https://hackerone.com/reports/148853 https://phabricator.wikimedia.org/T85850 https://phabricator.wikimedia.org/T85850

noblethrasher 9y ago
On the other hand, I think it would be straightforward to strip script tags and attributes using XSLT. You could even go as far as just whitelisting certain tags/attributes.
microcolonel 9y ago
> I havn't looked at it recently, but it used to be the case that hosting user submitted SVGs on your domain could yield JS-execution in the origin context. Oh definitely, though that's more an administrative problem than a platform problem. Webmasters (or whoever that task falls to today) must understand that SVGs are exactly as dangerous as HTML files in exactly the same ways. Where you would sanitize user-provided HTML, you must also sanitize user-provided SVG.