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

101–110 of 118 posts

Re: The woes of sanitizing SVGs

#101

Post by DarkUranium »

codedokode wrote: post #86

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.

Wrapping text is a bit tricky because of differences in text wrapping algorithms. Though I suppose an "easy" fix would be to be able to specify a very specific algorithm (to ensure equal representation across systems), or allowing custom (possibly better-quality) wrapping.

But for the most part, I 100% agree, and I've been considering making a format for my own use-cases. I think the biggest issue is in agreeing as to what subset is necessary; plus, of course, getting any level of adoption (though the latter isn't a factor for my own use ... except in the sense that there are no tools to help).

For example, do we need animations? Gradients? If so on the latter, what kind?

Re: The woes of sanitizing SVGs

#102

Post by Hendrikto »

> Stacking more and more complexity into sanitization is clearly a doomed approach. We are more than 5 major revisions deep and yet there are still known holes. People are actively sharing projects on the Scratch website bypassing SVG sanitization. And the moment browsers decide to implement the latest CSS specs, even more holes will open up.

This kind of stuff will get way worse with LLMs. They like just stacking more and more code on top of workarounds.

Re: The woes of sanitizing SVGs

#103

Post by jimmypk »

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…

[flagged]

Re: The woes of sanitizing SVGs

#104

Post by staticassertion »

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…

iframe sandboxing is wildly underleveraged. I think it's because it doesn't work well with "modern" app development - you need the ability to slice bits and pieces out yourself.

I've been just using plain typescript/html and it's so easy to say "yeah all of that rendered content goes into an iframe", I've got all of d3 entirely sandboxed away with a strict CSP and no origin.

I do hope that iframe sandboxing grows some new primitives. It's still quite hacky - null origins suck and I want a virtual/sandbox origin primitive as well as better messaging primitives.

Re: The woes of sanitizing SVGs

#105

Post by Pxtl »

I keep saying: I know there are good reasons we got "html but for vector art" but I wanted "jpeg but for vector art". I don't generally have to worry about sanitizing jpegs.

Re: The woes of sanitizing SVGs

#106

Post by simonw »

staticassertion wrote: post #104
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…

iframe sandboxing is wildly underleveraged. I think it's because it doesn't work well with "modern" app development - you need the ability to slice bits and pieces out yourself. I've been just using plain typescript/html and it's so easy to say "yeah all of that rendered content goes into an iframe", I've got all of d3 entirely sandboxed away with a strict CSP and no origin. I do hope that iframe sandboxing grows som…

I think the reason it's under leveraged is that there's so little useful documentation about it - particularly about its support in different browsers.

For something like this that's security critical I'd really like to see each of the browser vendors publishing detailed, trustworthy documentation about their implementations.

The technology itself is very widely deployed due to banner ads, so it's at least thoroughly exercised.

Re: The woes of sanitizing SVGs

#107

Post by hajile »

ikkun wrote: post #13

I do wish tinyVG or similar would take off, but I don't see that ever actually happening. the only thing I think it's missing is animation support, which is pretty niche but not as niche as tags. https://tinyvg.tech/

We need a secondary official SSVG (Secure SVG) spec so the changes can be guaranteed by browsers and other implementors.

This would allow an update to the xmlns to
Which would allow the image to force SSVG mode and disable all non-approved features, but you could also update the image tag so the client could force security on potentially insecure SVGs

Re: The woes of sanitizing SVGs

#108

Post by staticassertion »

simonw wrote: post #106
staticassertion wrote: post #104

Earlier quoted context omitted.

iframe sandboxing is wildly underleveraged. I think it's because it doesn't work well with "modern" app development - you need the ability to slice bits and pieces out yourself. I've been just using plain typescript/html and it's so easy to say "yeah all of that rendered content goes into an iframe", I've got all of d3 entirely sandboxed away with a strict CSP and no origin. I do hope that iframe sandboxing grows som…

I think the reason it's under leveraged is that there's so little useful documentation about it - particularly about its support in different browsers. For something like this that's security critical I'd really like to see each of the browser vendors publishing detailed, trustworthy documentation about their implementations. The technology itself is very widely deployed due to banner ads, so it's at least thoroughly…

It's multi-faceted. Docs is part of it, but also, no one cares about security and they won't do literally anything to improve security if there's a papercut.

Right now if I want to render untrusted content and if I use React I have to escape from using React to leverage this, using https://react.dev/reference/react-dom/server/renderToString

And using null origins has tons of UX problems - virtual / sandbox origins would solve this. https://gist.github.com/ddworken/309363b5d140bcc5ff6b39fa4a8...

There's just a lot more work to do before I expect to see this. It would solve so many problems though. I personally put d3, markdown rendering, etc, all into iframe sandboxes, which means the entire library could be malicious and it won't matter. But it requires way more effort than I'd like.

Re: The woes of sanitizing SVGs

#109

Post by kilna »

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

The rust resvg [1] project uses micro SVG (usvg) [2] as an interim normalization format that simplifies SVG into solely:

* Simplified paths (no shapes, only one kind of object)

* DTDs, Attributes, CSS and references are pre-resolved

* Invisible elements and comments are removed

Resolving shared items may cause sizes to increase drastically however. This is the sort of explosion that compression is perfect at compressing.

1: https://docs.rs/resvg/latest/resvg/ 2: https://docs.rs/usvg/latest/usvg/

Re: The woes of sanitizing SVGs

#110

Post by kilna »

pbhjpbhj wrote: post #96
bobthepanda wrote: post #59

Earlier quoted context omitted.

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?

> SVG was seen as a potential flash replacement?

Yes, that was a large part of the thrust back in the day. Even if it wasn't officially a goal of the SVG working group, there was a lack of an open standards-based alternative to what Flash was able to do, and the developers of the SVG standard saw that adding animation/tweening wouldn't take much given what browsers were already becoming capable of.

Post reply on HN