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

61–70 of 118 posts

Re: The woes of sanitizing SVGs

#61

Post by philo23 »

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?

The main use case I was thinking of is being able to use an inline SVG, but with external resources inside of it (like say a CSS background image using url(...)) in such a way that it ends up loading that embedded content in a cross-origin anonymous way and blocking all embedded scripts. That way someone can't make requests to CSRF exploitable URLs by setting an embedded images to something like example.com/my-submission/favourite

But also so that setting up a CSS transform: scale(10000) can't take over the entire viewport, it'd be constrained to an iframe-like boundary (exactly like an ) but still remain as an inline SVG, sort of like an . So scripts on the parent/host HTML document can still manipulate it like the rest of the DOM, but the inner elements are all "inert" for want of a better word.

Actually I don't know off the top of my head what happens with an SVG file inside of a when it references external images (either cross-domain or not.) I know scripts and animations get disabled, so I'd take a guess and say some CSS gets blocked too.

Again I've not really thought terribly hard about it, or if it's actually useful at all, and I'm betting it'd be filled with even more foot-guns than there are right now. I'm just thinking out loud.

Re: The woes of sanitizing SVGs

#62

Post by drfloyd51 »

Liftyee wrote: post #58

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?

Some of the suggestions are kind-of exactly that. But they specify not a change to the default behavior, but a new behavior based on the presence of a new attribute.

You could change the default behavior to the “safer” behavior. And then add some sort of “danger mode” attribute. But… devs are usually hesitant to do something that would break legitimate code, such as changing the default behavior would do.

Re: The woes of sanitizing SVGs

#63

Post by nmilo »

I'm sorry because I love the scratch project but this has to be said: they found XSS in SVGs in a surface with attacker-controlled access to Node and their fix was sanitizing it using regex??? And this was discovered by a user on scratch?

Even worse, OP's latest post "Every version of Scratch is vulnerable to arbitrary code execution" just tells you how exactly to exploit something similar today in the current version with no mention of responsible disclosure except a plug to say, "hey, check out my project, this one doesn't have RCE!" This is so irresponsible it borders on malicious.

Re: The woes of sanitizing SVGs

#64

Post by bawolff »

philo23 wrote: post #53
bawolff wrote: post #48

Earlier quoted context omitted.

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

Wouldn't that be the exact same as an tag? Img tag disables all scripting.

Re: The woes of sanitizing SVGs

#65

Post by nulltrace »

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.

Re: The woes of sanitizing SVGs

#66

Post by inkmuffin »

Devasta wrote: post #41

> In 2019, a few months after the initial release of Scratch 3, Scratch discovered that SVGs can contain tags that Scratch would cause to be executed when the SVG loads. This is known as an XSS. > Example from Scratch's test suite: Is this really an issue? This is the method that the chrome teams polyfill to replace XSLT suggests you do. https://github.com/mfreed7/xslt_polyfill/tree/main#usage

This was the example from their test suite. I didn't want to clone and build a 2019 copy of Scratch to test it end-to-end since the specifics weren't super important anyway.

Re: The woes of sanitizing SVGs

#67

Post by arcfour »

tracker1 wrote: post #26
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…

Nice, favorited... thinking this could be useful for an email reader to support css, but not scripts.

Most extant email readers support such a limited subset of CSS that nobody is likely to send emails with anything beyond very basic CSS though, unless your reader gains a ton of traction I suppose.

Re: The woes of sanitizing SVGs

#68

Post by inkmuffin »

Springtime wrote: post #7

It seems the reason they're inlined in the page at all is to measure things briefly like bounding boxes (not sure the full extent as it didn't cover that), before subsequent removal. I'm not familiar with Scratch and its use of user-submitted SVGs but I'd be curious to read more about what they're doing that required it be inlined specifically. (This isn't a comment on the challenges in proper sanitization fwiw, as I…

They want to run getBBox [1] which requires the SVG to be in the DOM somewhere - otherwise it throws an error. They need to do this because SVGs tend to have very inaccurate viewboxes, especially when working with SVGs made in old versions of Scratch. getBBox is the easiest way to get a more accurate understanding of how big the stuff in the SVG is.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/SVGGraphics...

Re: The woes of sanitizing SVGs

#69

Post by [deleted] »

philo23 wrote: post #61
somat wrote: post #55

Earlier quoted context omitted.

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

The main use case I was thinking of is being able to use an inline SVG, but with external resources inside of it (like say a CSS background image using url(...)) in such a way that it ends up loading that embedded content in a cross-origin anonymous way and blocking all embedded scripts. That way someone can't make requests to CSRF exploitable URLs by setting an embedded images to something like example.com/my-submis…

[deleted]

Re: The woes of sanitizing SVGs

#70

Post by inkmuffin »

nmilo wrote: post #63

I'm sorry because I love the scratch project but this has to be said: they found XSS in SVGs in a surface with attacker-controlled access to Node and their fix was sanitizing it using regex ??? And this was discovered by a user on scratch? Even worse, OP's latest post "Every version of Scratch is vulnerable to arbitrary code execution" just tells you how exactly to exploit something similar today in the current versi…

That post mentions that I disclosed this to Scratch in February 2024. The POC in that post is functionally identical to a POC I provided them back then and in various subsequent communications.
Post reply on HN