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

91–100 of 118 posts

Re: The woes of sanitizing SVGs

#91

Post by OneDeuxTriSeiGo »

xigoi wrote: post #90
OneDeuxTriSeiGo wrote: post #74

Earlier quoted context omitted.

it'd be nice if there was a way to declare in the URL that a given SVG could only be treated as an image so that you could safely open SVG urls, etc without exposing yourself to the dangers of embed/inline.

Couldn’t you do that using Content-Security-Policy?

If you control the domain then yes you could. But if I want to put a link on my website to some SVG hosted elsewhere and I want it to be safe for you to open that link in a new tab then there's not really a way for CSP to protect you the user from the host deploying a malicious SVG.

Like opening a PNG in a new tab is harmless but opening an SVG in a new tab is opening a pretty substantial can of worms.

Re: The woes of sanitizing SVGs

#92

Post by RobotToaster »

whycome wrote: post #11
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. :)

It always seems like any animated svg loses all of the animation after sanitizing

A lot of SVG animation uses JS for some reason. It would be interesting to see if sanitisers strip CSS and SMIL animation, I don't see any security reasons to do so.

Re: The woes of sanitizing SVGs

#93

Post by xigoi »

OneDeuxTriSeiGo wrote: post #91
xigoi wrote: post #90

Earlier quoted context omitted.

Couldn’t you do that using Content-Security-Policy?

If you control the domain then yes you could. But if I want to put a link on my website to some SVG hosted elsewhere and I want it to be safe for you to open that link in a new tab then there's not really a way for CSP to protect you the user from the host deploying a malicious SVG. Like opening a PNG in a new tab is harmless but opening an SVG in a new tab is opening a pretty substantial can of worms.

If your threat model is “I don’t want the image I’m hotlinking to be replaced with something else when opened in a new tab”, then no image format is safe.

Re: The woes of sanitizing SVGs

#94

Post by [deleted] »

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…

[deleted]

Re: The woes of sanitizing SVGs

#95

Post by gardaani »

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. :)

W3C has been defining SVG Native, but it hasn't progressed much lately — mostly because there hasn't been any interest in it. SVG Native is a small subset of SVG 2.0 which doesn't support scripting, animations or any external references. https://svgwg.org/specs/svg-native/

Re: The woes of sanitizing SVGs

#96

Post by pbhjpbhj »

bobthepanda wrote: post #59
thrance wrote: post #57

Earlier quoted context omitted.

Or you can literally just manipulate your SVG through the DOM in an external JS script... I still have no idea what the original motivation behind scripts in SVGs was.

I imagine it may have been attractive to those who liked Flash.

I think it may have been the other way (ie attractive to those who didn't like flash) - SVG was seen as a potential flash replacement?

Re: The woes of sanitizing SVGs

#98

Post by philipallstar »

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…

Wow - I had no idea. That's really useful, and probably much easier to implement by javascripters than something that might be set in nginx.

Re: The woes of sanitizing SVGs

#99

Post by philipallstar »

throwawayqqq11 wrote: post #88
NL807 wrote: post #82

Earlier quoted context omitted.

> SVGs should never have supported scripting. I would even go further: HTML should never have supported scripting.

... or third party requests. Scratch the H in HTML and internet tracking would have never happened.

You could track people without links. You just couldn't go to other places without links.

Re: The woes of sanitizing SVGs

#100

Post by som »

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 read this whole post silently mouthing a "CSP" mantra as each new vulnerability was discovered, years apart no less. Elated when I got to the revelation towards the end.

But for all my self righteous bluster the inline version was news to me. Hacker news. Awesome. Thank you.

Post reply on HN