This is what they actually use: https://github.com/flavorjones/loofah

Yes. Much better to handle all untrusted data safely rather than try to transform untrusted data into trusted data.

I found this page a helpful summary of ways to prevent SVG XSS: https://digi.ninja/blog/svg_xss.php

Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.

Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)

Yeah I’ve worked on a few pieces of software now that tried SVG sanitizing on uploads, got hacked, and banned the uploads.

I guess it is a matter of parsing svg. Trying to hack around with regex is asking for trouble indeed.

svgo is a minifier, not a sanitizer.

Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.

With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.

calling Leonard Rosenthol ...

Shouldn't the ignoring of scripting be done at the user agent level? Maybe some kind of HTTP header to allow sites to disable scripts in SVG ala CORS?

> But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work

That doesn't help too much if evil.svg is hosted on the same domain (with default "Content-Type: image/svg+xml" header), because attacker can send a direct link to the file.

They are like PDFs in that they do not render the same with different software or on different devices.

SVG can for example contain text elements rendered with a font. If the font is not available it will render in a different one. The issue can be avoided by turning text elements into paths, but not all SVGs do that.

More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.

PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.

Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.

The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.

SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.

There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.

There are multiple different parties involved with different priorities and different threshold for what features are sane to include:

- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic

- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer

- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality

- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths

Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.

From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.

Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.

And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.

Even PDFs don't always render the same from one platform to another. I've mostly seen it due to missing fonts.

Most renderers don't implement the full spec.

The Flash revisionism I see around here occasionally is bizarre.

No, Flash was terrible and killing it was good.

its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)

i wonder do people not do this with svgs?

Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.

Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.

I believe the username is from the AI simulation of HN in 10 years.

So if you're directly embedding the thing. This is a somewhat rare use case, should not be banned almost anywhere...

That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.

Does that mean that opening arbitrary pdfs on your laptop is unsafe?

Any notable examples you can share?