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

81–90 of 118 posts

Re: The woes of sanitizing SVGs

#81

Post by Nursie »

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

SVG Tiny PS (Portable Secure) is an attempt at this - https://www.ietf.org/archive/id/draft-svg-tiny-ps-abrotman-0...

Though I think it's still a draft, it does appear to be a requirement for BIMI - https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_I...

Re: The woes of sanitizing SVGs

#82

Post by NL807 »

pupppet wrote: post #54
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. :)

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.

> SVGs should never have supported scripting.

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

Re: The woes of sanitizing SVGs

#83

Post by gsnedders »

oldsecondhand wrote: post #75
bobthepanda wrote: post #59

Earlier quoted context omitted.

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.

AS2 was mostly following the direction of ES4 — so it wouldn’t have diverged if it hadn’t been abandoned.

Re: The woes of sanitizing SVGs

#84

Post by pornel »

somat wrote: post #55
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…

img src="file.svg" does that work for you?

This is not sufficient to stop XSS, because an attacker can redirect users to file.svg URL as the top-level document, bypassing restrictions of .

If you're going that route, add CSP headers on HTTP level to disable scripting, and/or host the SVG on a separate domain that has nothing valuable, or use data: URLs.

Re: The woes of sanitizing SVGs

#85

Post by 0x1ceb00da »

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

This is what android does. It has its own vector asset format and android studio has an action for importing svgs.

Re: The woes of sanitizing SVGs

#86

Post by codedokode »

I don't like that SVG uses things like CSS and JS and requires pulling in the whole browser to display. Instead of being a simple vector image format, it became just an extension of HTML. Maybe we need a new format, and if someone decides to do it, please add ability to embed fonts, wrap text and decent animations.

Re: The woes of sanitizing SVGs

#87

Post by codedokode »

hackeman300 wrote: post #18
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. :)

Seems like someone already implemented your idea. https://tinyvg.tech/

Maybe we could use a subset of SVG or PDF?

Re: The woes of sanitizing SVGs

#88

Post by throwawayqqq11 »

NL807 wrote: post #82
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.

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

Re: The woes of sanitizing SVGs

#89

Post by xigoi »

rslashuser wrote: post #60
chocmake wrote: post #31

Earlier quoted context omitted.

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 bal…

Exactly. It's not a good solution where you have to read a bunch of steps to do to make SVG safe, where you're worried you forgot one. Instead there should be a straightforward or whatever that simply and comprehensively disables the unsafe features. Think of prior technologies like display postscript and .doc, where a data format ended up a with big problems from its embedded "exec" type features.

Why not just use an tag?

Re: The woes of sanitizing SVGs

#90

Post by xigoi »

OneDeuxTriSeiGo wrote: post #74
nulltrace wrote: post #65

Earlier quoted context omitted.

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.

Couldn’t you do that using Content-Security-Policy?
Post reply on HN