Hacker News Reader

Comment by kodah | Hacker News Reader

Can't SVG's also be used to run code?

Yes, you can: https://stackoverflow.com/questions/5378559/including-javasc...

brb as I write a follow up article.

GitHub uses Camo [1] to serve assets like images and SVG files. It removes any "dangerous" code like JS from the file before serving it from a GitHub CDN.

1. https://github.com/atmos/camo

Are you sure?

Yes they use Camo, but that's a proxy to ensure that you don't serve JS from the same domain as github.com so that 3rd party assets have the JavaScript domain security policy applied.

I do not believe that Camo is a sanitising proxy... just a proxy.

Oh my! Never knew SVG was such a rabbit hole lol! Thanks for this info!

Ah svg, reminds me these fine windows metafile days.

Seriously, can we stop inventing formats that execute arbitrary code under the hood?

The problem isn’t SVG necessarily. It’s a nice vector format with many hidden features available to those who explore (especially with SVG 2 around the corner). The problem is JavaScript. Unfortunately, there’s not much one can do if they want interactive images[a][b] short of a Turing Complete language. And if you’re going to need that, JavaScript’s right there (for better or for worse).

[a]: Embedding the SVG directly into the HTML and manipulating it using the JavaScript in the HTML is an option, but not many people do that

[b]: We can argue all we want about whether we should be making interactive images in the first place, but the fact of the matter is, either you add it to your format, or someone else will

Every time someone does, someone else comes along and either presents a compelling enough use case that arbitrary execution is introduced or just wraps the thing in an environment where it’s funneled in.

Can svg's even do anything malicious with that capability?

Where they can execute JS, they can do so in the same security context as the containing document. So, yeah, they can be used in situ for any privacy or security intrusion that a script tag can.

This is not entirely correct. An SVG file embedded in an <iframe> or <object> is a document itself, and if cross-origin, can not access the outer document. However, if not in a sandboxed iframe, it can still do things like trigger alert prompts or navigation.

Sorry, this is right. I should have said it’s just as capable or limited in SVG as a bare script tag in the same place.

Camo is just a proxy that allows them to (a) always serve remote content from HTTPS and (b) more constrained CSP rules. Camo doesn't remove any code nor sanitize it.

Edit: I think I narrowed down where you were wrong! Github "raw" endpoints for repository files DOES have a sanitizing option. But that's not Camo (camo is for remote, non repo, assets (linked in comments or in markdown)).

I think allowing scripts and stuff in SVGs was a huge mistake that is why they are still not widely supported yet. For example you can't upload or send SVGs as images in typical messaging services or image sharing sited, in part because it would be a security vulnerability.

But as a consequence now we (still) have no easily portable vector format :'(

SVG is still a stupid format. Who wants to send image data through XML? It would be like sending a raster image through a big JSON array.

Who wants to send image data through XML?

SVGs aren't image data. They're a set of instructions for recreating image data using a structured language. XML is very good for data like that.

Text-based formats like XML and JSON are good if most of your data is strings, but storing numeric data in decimal strings is both inefficient and inaccurate. That's why I think that HTML is an appropriate use of XML-like markup but perhaps vector images would need a true binary version.

However I agree with saagarjha that it is very easy to write code to emit SVG, which is nice.

And their text format is exceedingly useful if you're writing code to generate them.

I don't think it would really be any more difficult if it were binary. The only real reason to use XML is better integration with HTML, CSS and JavaScript, which is admittedly a compelling reason.

But I think he's right - it would be nice if there was a "proper" binary vector format that was widely supported.

I mean, I can write a line of Python that goes

  print(f"""<rect x="{x}" y="{y}" width="{w}" height="{h}"/>""")

I find this eminently easier than working with a binary format.

That's a pretty error prone way of writing SVGs though. In well written code you would use a strongly typed API and that API would be exactly the same for a binary format.

Think about how you write Protobuf files for example.

In the circumstances where I actually cared I would use a strongly typed language with nice wrappers, of course ;) The reason why I love SVGs is you can just belt them out from scripts and it's the easiest thing in the world. Same reason why I love GraphViz and Netpbm.

SVG is vector. So basically XML is suitable for that task.

One could conceivably make a binary format based on Messagepack or Flatbuffers for vector data, which would be much more efficient and eliminate rounding problems of converting between floats and decimal numbers in text representations.

When you load an SVG file as an image, JavaScript is not executed, but SMIL animations and CSS (which includes animations) are.

If you open the SVG file directly, then JavaScript will be executed. But any hosting platforms that hosts your content on their domain should filter out any JavaScript on SVG as it would on HTML.

> But any hosting platforms that hosts your content on their domain should filter out any JavaScript on SVG as it would on HTML.

That's definitely not a thing that happens. Web servers just serve the file as-is.

The point is they either need to filter the served content, or serve it from a different domain (e.g. githubusercontent.com), otherwise you have XSS-like problems.

My understanding is that things like this are one of the reasons GitHub moved GitHub Pages subdomains from github.com to github.io.

GitHub raw endpoints do it. They will either serve the SVG without an image/svg+xml Content-Type, making it not render in the browser, or you have to append ?sanitize=true to the URL which will, as the name suggest, sanitize it.

ok but that is github...parent poster stated its common to do that...it is not.

It's web security 101 for handling user uploads. (although in the case of SVG most sites solve it by just not accepting "weird" formats like SVG)

See https://news.ycombinator.com/item?id=25350248

Yes, that’s what I am thinking. I can imagine hundreds of security researchers writing a proof of concept to report this “feature” as a security problem to GitHub’s bug bounty program.

There’s nothing to report. For all intents and purposes SVG files are treated exactly like images. All interactivity and even the ability to load other resources is disabled.

FYI millions of readmes have had SVG badges for years.

Pretty sure they're just making a joke that a lot of bug bounty programs get tons of bullshit reports from security "researchers" who don't understand what they're doing. They're not actually claiming there's a legitimate issue.

There are SVGs which will crash most browsers, so SVGs could still be abused for denial-of-service attacks.

For example, you could post one of those SVGs in every issue thread of a GitHub project if you wanted to mess with someone.

Not eligible for a bug bounty though since this issue has been known (but not fixed) for years.

I'm not sure that's true.

For example, what happens when you right-click "View image" on an svg file? Does embedded JS get run in that case?

> For example, what happens when you right-click "View image" on an svg file? Does embedded JS get run in that case?

Servers can use CSP http headers to disable javascript execution completely AFAIK. Obviously older browsers like IE that do not support CSP will be vulnerable, but at that point, IE should be simply banned by Webservers, for the sake of the user.

One version of the SVG standard had raw socket support, which thankfully was removed.

They basically wanted everything that Flash had.

I just tried this in a Github readme, it looks like Github removes the JS.

Would be interesting to try to find a hole in this.

There is no hole. The SVG is loaded as an image. If you find a hole, it would be in the browser’s handling of SVG images, which would be a pretty big hole.

Reply on news.ycombinator.com