Dokuwiki: Improved SVG support

[neuralyzer]

Since these days .svg is supported just fine by all browsers it would be really nice to improve svg support in dokuwiki. I think they could be treated just like bitmap files. In particular it would be great to have

• svg preview in the media manager
• and the same insert options as for bitmaps

I use .svg on my wiki all the time and it just works fine. Display, resize, floating ... all that works already.

[splitbrain]

Can you explain what you mean by "all that works already"? What did you do to enable SVG support? What kind of SVGs are you using? Are they set to autoscale or do they have fixed width/heights?

I'm not opposed to having native SVG support in DokuWiki but currently I'm not sure what that would need. For now http://doku.wiki/svgpurinsert seems to be the best way.

[neuralyzer]

Even without the svgpureinsert plugin I could already insert, align and resize svg using the ordinary dokuwiki syntax after I have added svg image/svg+xml to conf/mime.local.conf.
For example I would just do

{{image.svg?400}}

or

{{ image.svg?400}}

to align right (that is what I meant by "all that works already". Sorry for being imprecise.). And I just get the expected result in vanilla dokuwiki - no plugins required.

All the svgs I use have fixed width and height. I just upload the svgs inkscape produces. I actually don't note any difference after installing the svgpureinsert plugin. At least in my usesaces the svgpureinsert pluging does not seem to add any functionality dokuwiki doesn't already provide. (Maybe I just haven't encountered these usecases yet.)

[splitbrain]

Interesting. I didn't expect that. One more question: do you have imagemagick configured?

[neuralyzer]

Yes. I have set gdlib to "GD lib not available" and the path im_convert accordingly. But SVGs are really displayed as vector SVGs and not as bitmap images rasterized by imagemagick.

[brozkeff]

I would also prefer new installations of dokuwiki to contain native svg support active by default, so no need to enter svg image/svg+xml to the config file and optionally installing the plugin would be necessary. Modern browsers already support that reasonably well.

[michitux]

I think we definitely should NOT allow SVG uploads per default as they can contain JavaScript code and might enable a lot of possible attacks - or at least we should use a proper sanitizer. Have a look at this presentation and this guide about file upload vulnerabilities for some reasons why. Basically it's a huge security risk, as the presentation says "Allowing SVG for upload == allowing HTML for upload". Have a look at this question for some more opinions. Possible solutions might be to use something like SVG-Sanitizer (but this seems to be unmaintained, we should look for something actively maintained).

[neuralyzer]

It might be an idea to include for SVGs out of the box, treating them essentially like ordinary images, but disabling this option by default (as it is done with html).

[yurii-github]

is this security issue still valid?
As I know to execute any code you need to place in < svg> tag or <object>, if you put svg in <img> nothing happens

am I wrong?

regards

p.s. thanks for conf setting

[michitux]

The problem is afaik that in order to make embedding using the IMG tag possible, you need to allow viewing the image in the browser, i.e. opening it in a new tab. And there all JS and HTML code will be executed.

[cbellersen]

I don't know if that was recently changed in Dokuwiki, but now its super simple. You just need to enable .svg extensions for upload. To enable the “media” support for SVGs you need to edit or create conf/mime.local.conf and add at the bottom entry:
svg image/svg+xml

Then you can just add them to you Wiki code like this:
{{ my_file.svg |}}

[Klap-in]

@cbellersen, yes it is possible to let DokuWiki show your SVGs. But so far I know it still means this is technical similar to let your wiki users upload and show html and js files. So you have to really trust your users to upload only safe stuff.

[JadedDragoon]

Daryll Doyle created an SVG Sanitiser script in PHP that has worked well for me in the past. It even has integrated svg minification. I wrote an addon for Wordpress to auto-inline SVGs after sanitizing them, but it ran on page load (using apache's/nginx's caching to minimize the work load). Doing something like this on upload of svg files would be more ideal.

Judging by the number of svg-focused plugins for DokuWiki, most of them apparently abandoned, this seems to still be something people are interested in. Perhaps SVG Sanitizer could integrated as an optional dependency?

[michitux]

I found there is a relatively simple fix for making SVG (relatively) safe: just send the appropriate content-security-policy headers to completely disallow JavaScript execution. For example when I share an SVG image in a Matrix room, I get content-security-policy: sandbox; default-src 'none'; script-src 'none'; plugin-types application/pdf; style-src 'unsafe-inline'; media-src 'self'; object-src 'self';. We should look at other values, e.g. form-action 'none' sounds like a very good idea, too. Unless there are any issues with this I would suggest to just send such a header for all media files. I am not sure if enabling SVG by default is a good idea as SVG uploads would still allow presenting a completely different website including links that could allow sophisticated phishing attacks but I think the effects should be similar to using some sanitizer.

[splitbrain]

@michitux excellent idea!

[micgro42]

@michitux I still have to understand this better. Can we treat inline JS and JS in SVG differently? Because, IIRC, then we have a lot of inline JS, at least in plugins.
OTOH, I wonder if not almost all of those plugins might be quite old and outdated and it wouldn't exactly be bad if they stopped working as expected?

See #2198 for more discussions on this

[michitux]

@micgro42 We would not send this header for the main request but only for media files. This is only relevant for the case that you open the svg in its own browser tab/window, i.e., as its own page - when svg images are used in img tags, JavaScript is not executed anyway. I assume that this header is also respected when you, e.g., load the svg in an iframe. Note also that this disables JavaScript from all sources, not just inline script.

[micgro42]

Huh, that _might_ actually work :thinking: