I think some people on the SVG design committee were aiming to replace Flash for things like browser games, and wanted animations and javascript and so on to support that role.
That lead to the weird situation where browsers have two ways of embedding an SVG into a web page - embed in an <img> tag and the javascript won't run, but embed it in an <iframe> and it will (but of course iframe height can't auto-size...)
The javascript also means pretty much no user-generated-content sites allow the upload of SVGs. Wikipedia is the only place I can think of - and even they serve the SVG as a PNG almost everywhere.
> The Scalable Vector Graphics format is an open standard for rendering two-dimensional graphics.
It would be nice if we had one of those, but SVG is not it, at least not unless you’re willing to gloss HTML as “an open format for rendering reflowable text”. SVG is a full platform for web applications with fixed-layout graphics and rich animations, essentially Flash with worse development tools.
There have been some attempts to define a subset of SVG that represents a picture, like SVG Tiny, but that feels about as likely to succeed as defining JSON by cutting things out of JavaScript. (I mean, it kind of worked for making EPUB from HTML+CSS... If you disregard all the insane feature variation across e-readers that is.) Meanwhile, other vector graphics formats are either ancient and not very common (CGM, EPS, WMF/EMF) or exotic and very not common (HVIF, IconVG, TinyVG).
(My personal benchmark for an actual vector format would be: does it allow the renderer to avoid knowing the peculiarities of Arabic, Burmese, Devanagari, or Mongolian?)
SVG really is just an awful format. What the market wanted was a clean, easily parseable specification for vector image data based on a solid rendering specification. What it got was an extensible HTML-like scripting language where all the vector stuff was ad hoc and poorly implemented, and where (this is the bit that absolutely drives me up the wall) the actual image data is not stored in the metadata format they chose. You have to parse this entirely different string format if you want to extract the points on your curve or whatever!
All the more reason to block all JS by default with add-ons like NoScript or uBO and manage a whitelist.
It's a bit annoying the first few days, but then the usual sites you frequent will all be whitelisted and all that's left are random sites you come across infrequently.
> Security firm Malwarebytes on Friday said it recently discovered that porn sites have been seeding boobytrapped .svg files to select visitors. When one of these people clicks on the image, it causes browsers to surreptitiously register a like for Facebook posts promoting the site.
I think I'm missing something; if you can embed arbitrary JavaScript in the SVG, why is a click necessary to make that JavaScript run? And if JavaScript on your page can exploit CSRF on Facebook, why is embedding it in an SVG necessary?
I'm shocked this attack works. I thought the last 15 years of browser dev were largely isolating domains from each other to prevent cross-site attacks, and introducing consent flows for little used and/or dangerous platform features.
Running JS inside an image format sounds like a thing they could add permissions for (or a click-to-play overlay), especially if it can talk to other sites.
I want to make something clear: <img src=file.svg> will not execute any scripts nor load foreignObject.
For this to work, the SVG has to be loaded in an iframe or in a new tab. Or it could be inlined in the HTML.
Nothing special about SVG really as long as you (Facebook) treat SVG files as images and don't inline it.
The SVG part only really comes in as a way to hide script tags from anyone looking at the network requests, but even then it seems that the specific SVG was crafted to download further scripts.
So what's the issue here exactly? It seems that Facebook is still somehow affected by XSS? Neat.
> it causes browsers to surreptitiously register a like for Facebook posts promoting the site.
Wouldn't that be discovered pretty quickly, when Bob's family and friends see porn promoted to them because John apparently liked it on Facebook. Eventually, one of them would mention it to him.
"Y'know, Bob, you probably don't want to be liking that on your main Facebook account... Are you feeling OK?"
20 comments
[ 3.6 ms ] story [ 38.1 ms ] threadThe linked article just regurtitates the source.
That lead to the weird situation where browsers have two ways of embedding an SVG into a web page - embed in an <img> tag and the javascript won't run, but embed it in an <iframe> and it will (but of course iframe height can't auto-size...)
The javascript also means pretty much no user-generated-content sites allow the upload of SVGs. Wikipedia is the only place I can think of - and even they serve the SVG as a PNG almost everywhere.
Well there's your problem right there.
But does not fix the CSRF vulnerability, apparently.
It would be nice if we had one of those, but SVG is not it, at least not unless you’re willing to gloss HTML as “an open format for rendering reflowable text”. SVG is a full platform for web applications with fixed-layout graphics and rich animations, essentially Flash with worse development tools.
There have been some attempts to define a subset of SVG that represents a picture, like SVG Tiny, but that feels about as likely to succeed as defining JSON by cutting things out of JavaScript. (I mean, it kind of worked for making EPUB from HTML+CSS... If you disregard all the insane feature variation across e-readers that is.) Meanwhile, other vector graphics formats are either ancient and not very common (CGM, EPS, WMF/EMF) or exotic and very not common (HVIF, IconVG, TinyVG).
(My personal benchmark for an actual vector format would be: does it allow the renderer to avoid knowing the peculiarities of Arabic, Burmese, Devanagari, or Mongolian?)
Why are they clicking like buttons instead of stealing money from bank accounts then?
It's a bit annoying the first few days, but then the usual sites you frequent will all be whitelisted and all that's left are random sites you come across infrequently.
If you are a woman, did you know Facebook has been stealing menstruation data from apps and using it to target ads to you?
If you take photos with your smartphone, you know meta has been using them to train their ai? Even if you haven't published them on Facebook?
To say nothing of Facebook's complicity in dividing cultures and fomenting violence and hate...
I think I'm missing something; if you can embed arbitrary JavaScript in the SVG, why is a click necessary to make that JavaScript run? And if JavaScript on your page can exploit CSRF on Facebook, why is embedding it in an SVG necessary?
Running JS inside an image format sounds like a thing they could add permissions for (or a click-to-play overlay), especially if it can talk to other sites.
For this to work, the SVG has to be loaded in an iframe or in a new tab. Or it could be inlined in the HTML.
Nothing special about SVG really as long as you (Facebook) treat SVG files as images and don't inline it.
The SVG part only really comes in as a way to hide script tags from anyone looking at the network requests, but even then it seems that the specific SVG was crafted to download further scripts.
So what's the issue here exactly? It seems that Facebook is still somehow affected by XSS? Neat.
Wouldn't that be discovered pretty quickly, when Bob's family and friends see porn promoted to them because John apparently liked it on Facebook. Eventually, one of them would mention it to him.
"Y'know, Bob, you probably don't want to be liking that on your main Facebook account... Are you feeling OK?"
I see what you did there ;)