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.
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.
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.
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:
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.
Now that seems like a bug.
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...
It's things like these that lead to security issues.
Adobe, when they were trying to position SVG as a competitor to Macromedia's Flash.
No? PDF and PostScript are entirely different languages.
The thing I was trying to build was a graph drawing tool, so that’s why I figured SVG made sense.
It's doubtful it will work outside of the browser, and even in a browser, it will be static when used in an <img> tag.
As for where this will work: any SVG document viewer that implements the full spec should render this correctly, but you're correct in that it won't execute as document when used as an <img> source in the browser. Not due to anything related to SVG, but simply because that's what the HTML spec says <img> tags should do for any and all content pointe to by the "src" attribute:
"The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted."
So it is invalid to point to a scripted SVG, then?
So technically, no it's not "invalid" to point to a scripted SVG, but it better not execute the script. So it might not work the way you want, unless your goal is to see what it looks like without scripting!
>src must contain an URL referencing a resource that isn’t scripted
This says nothing about how agent must treat imgs not following these rules. This entire statement is useless, because the specification should explain what to do with given input, not what input must be. POSIX goes UB route, because it describes what to do to get what you want as a careful programmer. Browser cannot be described like that, because an input is random bytes over network that must be interpreted according to safety rules. But this description is pointless in both senses. It doesn’t specify what must happen on invalid input, nor does it describe the options.
Sorry for this rant, but this resembles to me how all other “web” tech is working and described. They just throw a pile of meaningless things together and pretend it’s done, because a reference implementation exists. No surprise there are browser wars and never-ending evolution of the same text-and-images spacerocket tech.
It's a cool idea, taking advantage of the fact that gifs can be partially decoded, then generate the next frame on the fly and then send it over to the client as part of the same request (hello comet!), but there's a number of practical (to the extent that either of these are practical) differences.
The svg can be downloaded, or cached, and it's functionality preserved (and can be viewed with a browser, even in offline mode). The gif solution technically would take an infinite amount of time to download. It requires an ongoing connection to the server, and it cannot be cached or distributed via a CDN.
So, not the same thing at all, but very interesting.
I think the spec authors and browser vendors are more than savvy enough to know that "img tags don't run scripts" is a security-relevant promise that authors will rely on; I'm not so convinced it's uniquely unreliable compared to the many other security-relevant corner cases out there.
There are other reasons to treat user-provided content specially, whatever format, so maybe you end up in a similar place no matter what. I just don't want folks to be left thinking that the behavior here is unspecified or such.
WARNING: MIGHT FREEZE YOUR BROWSER/OS. CLICK AT YOUR OWN RISK.
EDIT: interesting, your link made FF sweat, but it didn't stop working when I closed the tab - I had to manually kill the offending process.
Being able to upload arbitrary files has enabled many many web security bypasses, with the result ranging from xss to csrf.
"It's today," squeaked Piglet
"My favorite day," said Pooh
Oooooh that probably has some nefarious uses
See "ANNOTATION 3" here: https://svgwg.org/svg2-draft/interact.html#SVGEvents
Did anybody save this svg as a gist or anything?