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

71–80 of 118 posts

Re: The woes of sanitizing SVGs

#72

Post by zarzavat »

thrance wrote: post #57
pupppet wrote: post #54

Earlier quoted context omitted.

This is what happens when there isn't an adult in the room to reign things in, you get project overreach. SVGs should never have supported scripting. You want scripting in SVGs, fine, make it a different file format. I can't imagine the cumulative number of man hours wasted on this problem when the vast majority of users were just looking for a way to make their logos look sharp.

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.

While SVG is a web technology, for the longest time you had to install SVG support as a browser plug-in. I remember installing Adobe SVG viewer around 2000. It was used for interactive visualizations.

I'm don't remember precisely but I don't think you could script it from the DOM, I don't see how that could work if it's a plugin.

Re: The woes of sanitizing SVGs

#74

Post by OneDeuxTriSeiGo »

nulltrace wrote: post #65
etchalon wrote: post #21

I don't understand why it wasn't immediately understood that SVG is as dangerous as HTML. It is not, and never was, an image format. It's a markup language.

Browsers already treat the same SVG differently depending on how you embed it. strips scripts and external resource loads. and inline don't. People test with img tags, looks fine, then someone switches the embed method and everything opens up.

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.

Re: The woes of sanitizing SVGs

#75

Post by oldsecondhand »

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.

OG actionscript was very similar to Javascript. It only started to diverge when type hints were introduced.

Re: The woes of sanitizing SVGs

#76

Post by nine_k »

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

I would say that a proper sanitizer should remove any attribute that has /https?:/ in it. Maybe it should allow access to a subtree of a blessed domain you control, where stuff like textures is stored.

Re: The woes of sanitizing SVGs

#77

Post by esprehn »

spankalee wrote: post #2

This is, by the way, why Google Slides doesn't have SVG support even though there's a nearly 15 year old ticket requesting the feature.

They totally could sanitize it, just like they did with the gadget proxy, they just choose not to fix this ancient request.

It's like my ticket to add data url support to sheets. It just gets punted year after year.

Re: The woes of sanitizing SVGs

#80

Post by Grokify »

evilpie wrote: post #33

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

Good reference, along with the article. I built a SVG sanitizer in Go and will look to these to make it more strict.
Post reply on HN