Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The woes of sanitizing SVGs

muffin.ink

Post reply on HN
Print view View original

31–40 of 118 posts

Re: The woes of sanitizing SVGs

#31

Post by chocmake »

philo23 wrote: post #17

It'd be nice if there was a sandbox attribute you could add to inline tags, like the attribute that'd let you opt out of all the potentially "dynamic" stuff inside of an SVG like scripts and event handlers, or even just literally sandbox the entire thing from accessing the "parent" HTML page's context/cookies/etc just like an iframe. I'm sure it'd just open up a whole other can of worms though... not to mention havin…

Most of the aspects the author was critiquing are actually just regular CSS features, they simply don't want any external requests. Effectively they want inlined SVGs to be treated like how the browsers treat IMG-embedded SVGs (no scripting or external requests loaded).

Sanitization-wise it's already possible to strip scripting from SVGs and anything else you want, it's just that a library like DOMPurify to avoid ballooning in size doesn't include say a preset to handle the extra parsing necessary to make them behave like browsers treat IMG embeds, so it's up to devs to add their own.

But yeah, a world where a simple attribute to achieve the same effect as an IMG embed but for inlined SVGs would be nice.

Re: The woes of sanitizing SVGs

#33

Post by evilpie »

The HTML Sanitizer API has a subset of SVG that is allowed by the default configuration. It won't help you with sanitizing CSS at all however, style is simply not allowed by default.

https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...

https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...

Re: The woes of sanitizing SVGs

#34

Post by simonw »

recursive wrote: post #25
simonw wrote: post #20

I'm glad this article includes the only credible fix for the HTTP leak problems: CSP. A useful thing I learned recently is that, while CSP headers are usually set using HTTP headers, you can also reliably set them directly in HTML - for example for HTML generated directly on a page where HTTP headers don't come into play: "> It feels like this shouldn't work, because JavaScript in the untrusted content could use the…

I did not know about `srcdoc`, but it looks like that's still vulnerable to injection by using a double quote and to escape the sandbox. If this is constructed in a hygienic way using DOM manipulation, it seems like it could work, but it definitely seems possible to screw up.

You can entity-encode the content in the srcdoc= attribute to robustly solve that problem, or populate it via the DOM.

Re: The woes of sanitizing SVGs

#35

Post by simonw »

philo23 wrote: post #17

It'd be nice if there was a sandbox attribute you could add to inline tags, like the attribute that'd let you opt out of all the potentially "dynamic" stuff inside of an SVG like scripts and event handlers, or even just literally sandbox the entire thing from accessing the "parent" HTML page's context/cookies/etc just like an iframe. I'm sure it'd just open up a whole other can of worms though... not to mention havin…

Thankfully if you have CSP you don't need even basic sanitization, which is useful because most of the problems in this article are demonstrations of how simple sanitization isn't simple at all.

Re: The woes of sanitizing SVGs

#38

Post by RobotToaster »

andybak wrote: post #4

My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases". I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type. Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)

You'd lose a lot of useful features, like SMIL animation.

Re: The woes of sanitizing SVGs

#39

Post by andybak »

RobotToaster wrote: post #38
andybak wrote: post #4

My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases". I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type. Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)

You'd lose a lot of useful features, like SMIL animation.

But you'd gain adoption. A fair trade.

Re: The woes of sanitizing SVGs

#40

Post by sbrother »

varun_ch wrote: post #14
afavour wrote: post #12

Earlier quoted context omitted.

I think you're right but the lack of industry standard for this kind of thing kills it. People want to be able to take the output of whatever tool they use that exports SVG and put it in a browser. Which isn't an unfair request. But you wouldn't have a guarantee it wouldn't filter out the tool using some obscure SVG functionality. I'd love to see an agreed standard like OpenGL vs OpenGL ES for SVG. SVG-ES. Everyone a…

The way linked SVGs render from within img tags is basically perfect for SVG images (which as I understand is not standardized but is largely the same across browsers). External resources and scripting are blocked while still rendering nearly all SVGs correctly. And of course, any CSS is scoped to the SVG. If someone formalizes this as a new format, please give it a new name! tvg tiny vector graphics? savg safe vecto…

Maybe I'm missing something as I am not a frontend developer, but when you embed SVGs in an img tag as part of a Phoenix LiveView or even just a static component, you no longer get the ability to dynamically change paths/fills/colors with events coming from the server. Even if it's as simple as having a shape that you want to fill with a brand/highlight color, which at least for me is a common use case.
Post reply on HN