Hacker News Reader

Comment by drinchev | Hacker News Reader

> SVG supports JavaScript.

I didn’t know that, probably because I never had to use JS in a SVG.

Probably it works only when SVGs are rendered by a browser, so this feature is a bit of a hack for me.

It appears to be part of the spec, [0] although there appears to be no requirement for the SVG User Agent to support any particular scripting language.

This is interesting from a security perspective, because it effectively means SVGs can contain scripts. If I was a security researcher, this sort of little-known but apparently widely supported feature is exactly where I would be looking for vulnerabilities.

[0] https://www.w3.org/TR/SVG/script.html#ScriptElement

> If I was a security researcher, this sort of little-known but apparently widely supported feature is exactly where I would be looking for vulnerabilities.

Well, it's not really a thing. In a browser (the only kind of UA that'll really run any scripts in an SVG), SVG basically gets treated as SGML, all the DOM stuff is the same. If you include it as an image tag, the scripts don't tend to run, AFAIK.

Added to clarify: The types of things you could exploit in a scripted SVG but which wouldn't also apply to HTML, would tend to be exploitable in a static SVG as well.

> Well, it's not really a thing. In a browser (the only kind of UA that'll really run any scripts in an SVG), SVG basically gets treated as SGML, all the DOM stuff is the same. If you include it as an image tag, the scripts don't tend to run, AFAIK

It breaks expectations. I havn't looked at it recently, but it used to be the case that hosting user submitted SVGs on your domain could yield JS-execution in the origin context. Embedding or iframing without sandbox isn't/wasn't secure either.

A quick google search on SVG XSS gives:

https://hackerone.com/reports/148853 https://phabricator.wikimedia.org/T85850

On the other hand, I think it would be straightforward to strip script tags and attributes using XSLT. You could even go as far as just whitelisting certain tags/attributes.

> I havn't looked at it recently, but it used to be the case that hosting user submitted SVGs on your domain could yield JS-execution in the origin context.

Oh definitely, though that's more an administrative problem than a platform problem. Webmasters (or whoever that task falls to today) must understand that SVGs are exactly as dangerous as HTML files in exactly the same ways. Where you would sanitize user-provided HTML, you must also sanitize user-provided SVG.

That's a relief. I see from the page it's embedded as an iframe, which I didn't know you could do. Changing the iframe to an img on the page does indeed prevent the script executing, at least on Firefox.

Proof that it doesn't work when used in an <img> tag: https://jsfiddle.net/8rcrfpwn/

It does work with an <object> tag, though: https://jsfiddle.net/8rcrfpwn/4/

The script also works if the SVG is written inline. Sadly, WordPress makes that tricky on my site.

So let's say you use an img tag, but the user right clicks and chooses view image? Navigating to the svg seems to run the scripts.

> Navigating to the svg seems to run the scripts.

Now that seems like a bug.

If I recall correctly, Mozilla thought so too and recently disabled scripts in direct SVG navigation and data: URIs in recent versions of Firefox.

Well, direct navigation worked when I tried it now and I can't seem to turn up the blog post I thought commented on the situation, so my recollection here may be in question.

Normally this isn’t a problem. If the SVG is included with an <img> Tag the JS won’t execute. If you directly embed the SVG tags into the HTML it will. But surely no one does this with SVGs they receive from untrustworthy 3rd parties right?

Except a web performance best practice (for non-H2 sites) is to inline images into the HTML... and there are some auto-optimizing libraries that will embed SVG as <SVG> tags instead of as a data: URI...

Yep. I know of a few persistent XSS vulns in a few top Alexa sites because of this :-D

    a web performance best practice (for non-H2 sites) is to
    inline images into the HTML... and there are some auto-
    optimizing libraries that will embed SVG as <SVG> tags
    instead of as a data: URI...

When I worked on mod_pagespeed (a website auto-optimizer) we wouldn't have it touch SVGs at all because there are so many potential security issues there. (And it wasn't widely used enough to be worth it given the risks.)

Thanks for your work on mod_pagespeed. It was an awesome approach for FEO. It's not that problem. I see this issue primarily in some semi-popular build/publishing plugins.

Honestly, they should treat those as two different formats - like SVG and WSVG or something. Dumb file vs vector-graphics web-application platform.

Yep, talk about scope creep...

I think back to the XML readers and XSLT parsers that could read arbitrary files or the fact that you can technically embed flash in a PDF (which is just a wrapper around Postscript).

It's things like these that lead to security issues.

Honestly when I read that first line about SVG and Javascript, I was a little horrified. Who the fuck on what planet ever though that could possible be a good idea?

> Honestly when I read that first line about SVG and Javascript, I was a little horrified. Who the fuck on what planet ever though that could possible be a good idea?

Adobe, when they were trying to position SVG as a competitor to Macromedia's Flash.

It's the antithesis of good design. But that doesn't surprise me, coming from the company that designed the clusterfuck that is pdf. It's ubiquitously in everything tech, and an absolute nightmare to embed.

> PDF (which is just a wrapper around Postscript)

No? PDF and PostScript are entirely different languages.

JS in SVGs is very useful. See for example Gregg's flame graphs: http://www.brendangregg.com/flamegraphs.html

I got a bug bounty [1] on Shopify because of a similar feature in SVG, external sources. I've been saying this for a while: if you are parsing svg server side you are most likely vulnerable to these type of attacks. SVG files should be considered programs from a security standpoint.

[1] https://hackerone.com/reports/97501

I wish there was a SVG-lite / SVGL standard that is a subset of SVG.

There is SVG Tiny - https://www.w3.org/TR/SVGTiny12/ - designed when phones were less powerful than today.

I once started building a web application based on SVG, but if I remember correctly I gave up because it was harder to debug JavaScript running inside of an SVG compared to JavaScript running from HTML.

The thing I was trying to build was a graph drawing tool, so that’s why I figured SVG made sense.

It was quite a while ago though and I am much more experienced now than I was back then so maybe I could have pulled it off better now but honestly I don’t see a reason to try. If I were to make my graph editor tool I’d just build it as a regular web app now. I might still utilize SVG, or I might do it with canvas but either way I wouldn’t do it with the JavaScript running inside of the SVG this time I think.

How does something like SVG even end up in HTML spec? It seems like there could be millions of such technologies but we end up with things like JS, SVG, XSLT.

I immediately thought what about webmail, like gmail? Gmail doesn't run JS in emails, would it in an SVG?

Yeah, probably another entrypoint for xss.

Reply on news.ycombinator.com