Live data from Hacker News

The woes of sanitizing SVGs

muffin.ink

111–118 of 118 posts

Re: The woes of sanitizing SVGs

#111

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?

a little bit of a, a little bit of b. to displace flash if you don't like it, SVG has to have flash-like features to appeal to those who do use it and steal them away.

Re: The woes of sanitizing SVGs

#112
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…

You can also use JS to inject a CSP and it will enforce the strict most policy.

Re: The woes of sanitizing SVGs

#113
post #43

Earlier quoted context omitted.

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…

What switch?

Whether macros are enabled.

Re: The woes of sanitizing SVGs

#114
post #93

Earlier quoted context omitted.

If you control the domain then yes you could. But if I want to put a link on my website to some SVG hosted elsewhere and I want it to be safe for you to open that link in a new tab then there's not really a way for CSP to protect you the user from the host deploying a malicious SVG. Like opening a PNG in a new tab is harmless but opening an SVG in a new tab is opening a pretty substantial can of worms.

If your threat model is “I don’t want the image I’m hotlinking to be replaced with something else when opened in a new tab”, then no image format is safe.

That's not particularly true?

A malformed JPEG or PNG might have potential vulnerabilities but they are considered a failure of the browser or parser lib to mitigate.

An SVG however has vulnerabilities and those are directly built into the spec of well formed SVGs.

Re: The woes of sanitizing SVGs

#115
post #93

Earlier quoted context omitted.

If your threat model is “I don’t want the image I’m hotlinking to be replaced with something else when opened in a new tab”, then no image format is safe.

That's not particularly true? A malformed JPEG or PNG might have potential vulnerabilities but they are considered a failure of the browser or parser lib to mitigate. An SVG however has vulnerabilities and those are directly built into the spec of well formed SVGs.

What vulnerabilities do you have in mind?

Re: The woes of sanitizing SVGs

#117
post #115

Earlier quoted context omitted.

That's not particularly true? A malformed JPEG or PNG might have potential vulnerabilities but they are considered a failure of the browser or parser lib to mitigate. An SVG however has vulnerabilities and those are directly built into the spec of well formed SVGs.

What vulnerabilities do you have in mind?

Well as an example: Lets say I maintain a hypothetical appview for an atproto service and we support SVGs. Users can upload SVGs via our appview or directly to their PDS and we pick them up when the network propagates record updates.

So users can view SVGs embedded in our site and they are regular vanilla SVG images. But say the user copies a link to this image (which we serve via our site or a CDN).

They share the image to a friend via URL and their friend clicks the link opening it directly in firefox or chrome. Now all the scripts in the SVG can execute and the image can rewrite the DOM to present itself as a fake website prompting them to log into their bluesky/atproto account to view the content. So said friend types their credentials in and the script in the SVG sends that back to their C&C server.

Re: The woes of sanitizing SVGs

#118
post #67

Earlier quoted context omitted.

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.

Most people just read within the context of a browser, and a lot of readers are using a browser engine. FWIW, this is how a lot of worms in around 1999-2000 got around is because of a few stupid security context mistakes.
Post reply on HN