is santizing SVGs hard, or just everyone forgets they can contain js?

rslashuser 17 hours ago | parent | next [-]

I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.

I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!

Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.

▲

css_apologist 16 hours ago | parent | next [-]

its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)

i wonder do people not do this with svgs?

	▲	15 hours ago \| parent [-]
		[deleted]

▲

staticassertion 12 hours ago | parent | prev [-]

Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.

Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.

	▲	rslashuser 9 hours ago \| parent [-]
		I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.

▲

AmbroseBierce 17 hours ago | parent | prev [-]

User name checks out.

	▲	coolcoder613 10 hours ago \| parent [-]
		I believe the username is from the AI simulation of HN in 10 years.