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

51–60 of 118 posts

Re: The woes of sanitizing SVGs

#51

Post by bawolff »

LorenPechtel wrote: post #15
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. :)

Yeah, I think that's the real answer. Look at what Microsoft did with Excel--the dangerous stuff is behind a switch. Thus, solution: Add two bits to the tag. SVG1 does not execute any sort of script. SVG2 does not follow links. SVG3 is actually SVG1 + SVG2 as these are bit flags, not numbers. Additional bits are reserved for future use if any other issues are found. The only real safety is in the engine, not by any s…

Which is essentially already how it works. See https://svgwg.org/specs/integration/#secure-animated-mode

Re: The woes of sanitizing SVGs

#52

Post by Avamander »

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

There's the SVG Tiny profile that some implementations use, like BIMI/VMCs.

Re: The woes of sanitizing SVGs

#53

Post by philo23 »

bawolff wrote: post #48
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…

I dont see how that could work, as an tag in html is not a document boundry. How can you prevent it from accessing a parent doc when its not a separate document. There is iframe srcdoc if you want to do this.

> How can you prevent it from accessing a parent doc when its not a separate document.

By turning it into a document boundary when you use the sandbox attribute, kinda similar to loading an svg file inside of an tag.

and yeah you could get 90% of the way there with an iframe srcdoc, but I was imagining some kind of cross between an sandboxed into its own origin, and an where it still has its own intrinsic size.

but it was mainly just a throw away thought, I've not really thought it through much deeper than that.

Re: The woes of sanitizing SVGs

#54

Post by pupppet »

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.

Re: The woes of sanitizing SVGs

#55

Post by somat »

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?

Re: The woes of sanitizing SVGs

#57

Post by thrance »

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.

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.

Re: The woes of sanitizing SVGs

#58

Post by Liftyee »

I'm not familiar with the details of real software development, so I don't know why it's not possible to just "not give the SVG part of the code internet access" or "perform sanitization on post-decoding (url, hex, etc) data".

Is it because the SVG parser/renderer being used is an entire library, and it would be prohibitive to write your own SVG parser/renderer or insert your own code into the existing one?

Re: The woes of sanitizing SVGs

#59

Post by bobthepanda »

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.

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

Re: The woes of sanitizing SVGs

#60

Post by rslashuser »

chocmake wrote: post #31
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 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.

Post reply on HN