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?
The woes of sanitizing SVGs
111–118 of 118 posts
Re: The woes of sanitizing SVGs
#112I'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…
Re: The woes of sanitizing SVGs
#113Earlier 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?
Re: The woes of sanitizing SVGs
#114Earlier 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.
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
#115Earlier 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.
Re: The woes of sanitizing SVGs
#116Re: The woes of sanitizing SVGs
#117Earlier 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?
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
#118Earlier 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.