Support SVG graphics in Joomla

[David White]

I recently raised an issue regarding SVGs (http://bit.ly/v1Rudy) and
was asked to raise it as a discussion here.

In Joomla you currently can't upload SVG graphics by the usual routes
(media manager or the insert image dialogue) because it is rejected as
a possible XSS attack. This check looks for HTML-like syntax (of which
SVG has plenty) and for the sake of IE6 blocks the image.

I'd like this behaviour to be reviewed. Firstly because IE6 is no
longer supported and secondly because SVGs are becoming more popular.

I'm developing Joomla modules and plugins to inline SVGs into XHTML.
The results are promising with features such as SMIL animations and
server-side rendering for mobile / old IE browsers. However, the
behaviour of Joomla is affecting usability.

I'd suggest that SVG is a technology that is likely to appear more and
more with recent developments such as mobile browsers dropping Flash
and developing SVG support. SVG is also supported by HTML5. Now is the
time to change Joomla's behaviour towards it.

I'd suggest either being able to disable the XSS checks or make them
more intelligent, by looking for scripting references rather than HTML-
like syntas and having the option to warn the user uploading the
image. This could be set by site policy.

[Hannes Papenberg]

Full ACK. Please make the code more intelligent. :-)

Hannes

[Rouven Weßling]

I'm all for more SVG in the Web, but where does it say that this check is only there for the sake of IE6? IMO it would be good to find out why exactly that check was aded and if it's still valuable to prevent this risk find a different solution that doesn't block SVG images.

Rouven

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>

[David White]

On Dec 4, 7:18 pm, Rouven Weßling <m...@rouvenwessling.de> wrote:
> I'm all for more SVG in the Web, but where does it say that this check is only there for the sake of IE6? IMO it would be good to find out why exactly that check was aded and if it's still valuable to prevent this risk find a different solution that doesn't block SVG images.

This article states it's for the sake of IE6 - http://docs.joomla.org/Possible_IE_XSS_Attack

The code itself doesn't have any comments

[Jennifer Marriott]

It isn't just because of IE6 I thought.  I could be wrong but I thought SVGs can be dangerous because they can contain content from multiple origins amd external media such as images,video, audio, style sheets, and scripting languages etc?

Wouldn't that be a serious security problem unless you can check the SVG upload to make sure it is secure?

I admit I may be misunderstanding the issue.  Would love to know more from the experts on it.

[David White]

You could be right about not-just-IE6 but that's the only concrete
reference I can find to why this feature exists.

It's true that SVGs can contain references to external content but we
allow flash uploading and that has similar features. I suppose it has
a similar set of issues as an html frame referencing external content
such as how you would use Google Maps. The browser is supposed to
protect you from missuses of html and similarly with SVG. So, a script
in a referenced SVG image shouldn't be able to manipulate or examine
the rest of the page it is embedded in - that would be a serious XSS
security problem. However, an embedded script is probably just an
animation or similar, just like how you'd use javascript in html, and
is a desirable feature.

If you've got a tightly managed website (e.g. a company site with
trusted authors) you may want a warning for uploading an SVG with a
script but you'd want to allow it because someone in the marketing
department has created an animation.

However, if you run a public website with user contributions you might
want to bolt down on SVGs with scripts or, for that matter, any sort
of external content reference.

in the future, with iOS not having flash but having SVGs + SMIL +
javascript, and Android going the same way, and Microsoft going all
HTML5-with-no-plugins (aka flash) people are going to increasingly use
SVG and we need to support it.

On Dec 4, 11:38 pm, Jennifer Marriott <marpomultime...@gmail.com>
wrote:

[Nicholas K. Dionysopoulos]

Stupid question: Isn't this exactly why we can customise the list of allowed extensions and MIME types in the Media Manager?

Moreover, couldn't we just add a pair of configuration fields "Enable XSS check for these files types" and "Enable XSS check for these mime types"?

Just throwing some ideas around :)

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[brian teeman]

You might find this presentation about the "security" of svg useful http://www.hackinparis.com/talk-forbidden-image-svg

[David White]

I agree with adding XSS check options. What would be ideal is more
intelligent XSS checking (look for scripts and external links rather
than html-like syntax) and the option to either block or the option to
warn.

On security I like the quote "Allowing SVG for upload == allowing HTML
for upload" from the very good presentation referenced by Brian. That
is the security implication and why we need better XSS checking.

-David.

[Jennifer Marriott]

Thank you Brian for posting that link. Great information.

[Sam Moffatt]

Blast from the past. That bug fix is 4 years old! And we're still
fighting IE6 issues.

The problem is that IE6 does its own sniffing for content type and
sometimes gets it wrong. So you could upload a file that is innocuous
in most browsers (SVG included) however when a user in IE6 looks at it
if it contains HTML tags (our filter list noted below) in the first
256 bytes, IE6 will actually instead determine it to be a HTML
document (not this strange image/svg+xml thing) and then will run what
ever code is in there. It really has nothing to do with the user
uploading the image and more to do with potential random users on the
web who run IE6 and your site being a potential platform for malware
attack. And since we all use newer browsers we're never going to see
those attacks.

This is why it looks the way it does because its specifically matching
the behaviour of IE to counter this particular bug. Removing it could
make Joomla! a platform for this particular form of IE attack.

Cheers,

Sam Moffatt
http://pasamio.id.au

List of tags:
'abbr','acronym','address','applet','area','audioscope','base','basefont','bdo','bgsound','big','blackface','blink','blockquote','body','bq','br','button','caption','center','cite','code','col','colgroup','comment','custom','dd','del','dfn','dir','div','dl','dt','em','embed','fieldset','fn','font','form','frame','frameset','h1','h2','h3','h4','h5','h6','head','hr','html','iframe','ilayer','img','input','ins','isindex','keygen','kbd','label','layer','legend','li','limittext','link','listing','map','marquee','menu','meta','multicol','nobr','noembed','noframes','noscript','nosmartquotes','object','ol','optgroup','option','param','plaintext','pre','rt','ruby','s','samp','script','select','server','shadow','sidebar','small','spacer','span','strike','strong','style','sub','sup','table','tbody','td','textarea','tfoot','th','thead','title','tr','tt','ul','var','wbr','xml','xmp','!DOCTYPE',
'!--'

On Mon, Dec 5, 2011 at 5:54 AM, Jennifer Marriott
<marpomu...@gmail.com> wrote:
> Thank you Brian for posting that link. Great information.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/FxnPjZeNpnIJ.

[piotr_cz]

Hi, this may be similar issue to the post I just sent (JInput & xml:
https://groups.google.com/group/joomla-dev-platform/browse_thread/thread/18513651904d784c).

In short: I'm having difficulties in retrieving XML using JInput
(filters clean up all tags) and SVG uses XML.
piotr

On Dec 24, 2:24 pm, Sam Moffatt <pasa...@gmail.com> wrote:
> Blast from the past. That bug fix is 4 years old! And we're still
> fighting IE6 issues.
>
> The problem is that IE6 does its own sniffing for content type and
> sometimes gets it wrong. So you could upload a file that is innocuous
> in most browsers (SVG included) however when a user in IE6 looks at it
> if it contains HTML tags (our filter list noted below) in the first
> 256 bytes, IE6 will actually instead determine it to be a HTML
> document (not this strange image/svg+xml thing) and then will run what
> ever code is in there. It really has nothing to do with the user
> uploading the image and more to do with potential random users on the
> web who run IE6 and your site being a potential platform for malware
> attack. And since we all use newer browsers we're never going to see
> those attacks.
>
> This is why it looks the way it does because its specifically matching
> the behaviour of IE to counter this particular bug. Removing it could
> make Joomla! a platform for this particular form of IE attack.
>
> Cheers,
>

> Sam Moffatthttp://pasamio.id.au
>
> List of tags:
> 'abbr','acronym','address','applet','area','audioscope','base','basefont',' bdo','bgsound','big','blackface','blink','blockquote','body','bq','br','but ton','caption','center','cite','code','col','colgroup','comment','custom',' dd','del','dfn','dir','div','dl','dt','em','embed','fieldset','fn','font',' form','frame','frameset','h1','h2','h3','h4','h5','h6','head','hr','html',' iframe','ilayer','img','input','ins','isindex','keygen','kbd','label','laye r','legend','li','limittext','link','listing','map','marquee','menu','meta' ,'multicol','nobr','noembed','noframes','noscript','nosmartquotes','object' ,'ol','optgroup','option','param','plaintext','pre','rt','ruby','s','samp', 'script','select','server','shadow','sidebar','small','spacer','span','stri ke','strong','style','sub','sup','table','tbody','td','textarea','tfoot','t h','thead','title','tr','tt','ul','var','wbr','xml','xmp','!DOCTYPE',

[Sam Moffatt]

Completely unrelated, this code only runs in the media manager for
uploaded files and anywhere else utilising that helper.

Cheers,

Sam Moffatt
http://pasamio.id.au

[David White]

Update on SVG and Joomla. The following site uses SVGs extensively.
I've developed extensions to inline SVGs and add SMIL + Javascript
animations on the fly. Uploading the graphics files is a pain and not
good for a standard user. I'm using extplorer rather than the media
manager and I wouldn't let a general user do that. Could really,
really do with Joomla not being hobbled by IE6.

www.theprayerhouse.co.uk

-David.

[Sam Moffatt]

I think the world could do with not being hobbled by IE in general.
However wishing the browser out of existence doesn't make it so
otherwise it'd be gone many years ago. This article, and some of the
links inside it, seem to imply that IE still does MIME sniffing even
in later browsers:
http://blogs.msdn.com/b/ie/archive/2010/10/26/mime-handling-changes-in-internet-explorer.aspx

However even if only IE6 or lower is impacted and if Microsoft's own
countdown is to be believed then roughly 7.7% of people still use the
browser[1]. I we assume there is over a billion[2] users removing a
protection such as this makes over 77 million people vulnerable.

Cheers,

Sam Moffatt
http://pasamio.id.au

[1] http://www.ie6countdown.com/
[2] http://en.wikipedia.org/wiki/List_of_countries_by_number_of_Internet_users
[3] http://www.h-online.com/security/features/Risky-MIME-sniffing-in-Internet-Explorer-746229.html

[David White]

It's true, Microsoft's browser update policies means we are lumbered
with old browsers for years after they really should have been
upgraded. however, the rest of the web moves on. Flash is on it's last
legs with Adobe having dropped mobile support and HTML5+SVG is moving
into that gap. IE9, Chrome, Firefox, Safari, Android and iOS all
support SVG. Whilst we can't wish IE6 away we also need to keep up
with current technology. Something needs to be done differently here
for SVGs because Joomla currently is hobbled because of IE6 and this
situation can only get worse with time.

[Sam Moffatt]

It isn't about the browser supporting or not supporting SVG. It is
about IE's desire to flagrantly ignore the server and take a perfectly
legitimate looking image file and decide it's HTML and start executing
it. Or any other otherwise perfectly valid looking file. The insidious
aspect is that the image could be entirely legitimate however as it
has something resembling HTML in the first 200 characters IE decides
it has to be HTML which means you now have a platform for launching an
XSS attack from an image file. When you open such an insidious file
using any other tool the file looks fine however perhaps it's JFIF or
PNG comment contains a malicious payload.

As noted in the previous email, it looks like IE6 is not the last
browser with this "feature" and that it would appear it persists into
IE8 and potentially later. IE will ignore MIME types it doesn't know
from the server and only play russian roulette with the MIME type when
it thinks it knows what it's doing - which really doesn't make it any
safer.

Given that potentially IE6 through the unreleased IE10 could still be
vulnerable to this form of attack (which is to say, beyond a joke by
now), I don't see any way of removing the check without putting in a
potential security vulnerability.

Sam Moffatt
http://pasamio.id.au

[David White]

Something really has to be done differently. MIME sniffing is a bad
idea but not a vulnerability per se, the vulnerability was XSS which
was supposed to be fixed years ago. Now Joomla is taking the
responsibility of making sure this one vulnerability doesn't happen
again but in the process missing the boat on new technology.

What could be done? Here are some examples.

* This form of attack is a lot less of a problem on sites managed by a
few (trusted) people so have the option to turn it off.
* Or, don't check XML content such as SVGs at all
* Or, have options to disallow certain features of XML (e.g. option to
disallow script and another to disallow SMIL).

[Sam Moffatt]

Yes, we can trust that when Microsoft say all their vulnerabilities
are gone that this is most definitely the case.

http://www.youtube.com/watch?v=PqiimrFwtBs

Again, we're back to the even if it is only IE6 which is still
globally over 7% and shrinking however that is still upwards of 70
million potentially impacted users. Still a lot of people to be
impacted, however looking at this link[1] the comments seem to imply
that IE7 on Vista was still vulnerable to the attack though later
comments suggest that some updates might have closed the hole. This
page seems to suggest that while PNG's were locked down, other types
were potentially still vulnerable[2]. I can't seem to replicate the
issue using IE8 with the resources provided in [1] however, so perhaps
it's fixed or perhaps it's just those test cases that Microsoft have
cleaned up. Given IE7 was still vulnerable for a period of time,

The problem is that even with trusted users, if you have a file
potentially from an untrusted source it can be used as a vector to
attack the site. It may be less risk but there still exists a risk.

Cheers,

Sam Moffatt
http://pasamio.id.au

[David White]

So if we're inspecting binary formats for this sort of attack, does
that preclude treating SVG differently?

[Sam Moffatt]

We're inspecting all uploads regardless of where they come from or
what they say they are because by definition they're not what they're
pretending to be.

Cheers,

Sam Moffatt
http://pasamio.id.au

On Fri, Feb 3, 2012 at 4:20 AM, David White <da...@netriver.co.uk> wrote:
> So if we're inspecting binary formats for this sort of attack, does
> that preclude treating SVG differently?
>

[David White]

Thank you for your reply, Sam,

What you say is true but it's not quite against treating different file types differently. By all means check that GIFs, PNGs and SVGs don't contain what they shouldn't. Check them all. But do it intelligently. Clearly the rules for binary files (must contain nothing that looks like XML) is different from SVGs (disallow Javascript and external references).

SVGs are ideal for mobile, for retina displays, desktop PCs. They are used by a number of sites including Google analytics. Even IE supports them. It's time Joomla worked out how to support them, I think.

-David.

On Sunday, 22 April 2012 20:02:18 UTC+1, Samuel Moffatt wrote:

We're inspecting all uploads regardless of where they come from or
what they say they are because by definition they're not what they're
pretending to be.

Cheers,

Sam Moffatt
http://pasamio.id.au

On Fri, Feb 3, 2012 at 4:20 AM, David White <da...@netriver.co.uk> wrote:
> So if we're inspecting binary formats for this sort of attack, does
> that preclude treating SVG differently?
>
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Don]

On Sunday, April 22, 2012 5:35:11 PM UTC-4, David White wrote:

It's time Joomla worked out how to support them, I think.

+1 

[Sam Moffatt]

And you know for sure that versions of IE won't ignore the SVG and
inflict the bug regardless?

I don't think you understand the bug. The bug is that IE ignores
everything and does stupid stuff regardless of the actual contents of
the file because it thinks it knows better. It isn't about us getting
smart, it's about the eradication of the browser's behaviour to think
it knows better regardless of what you tell it. The intelligence we
have is that the file could be detected by that browser as being HTML
and we're aiming to prevent files that look like that from being
uploaded in case they aren't legitimate. One could certainly hide a
relevant payload in an SVG image just as easily as any of the binary
file types. The trap is that if it looks like HTML, IE decides it is
HTML and treats it as it was a HTML document even though it isn't.

We wouldn't have this feature if it wasn't for that browser.
Unfortunately said browser still exists.
We can't fix that the browser still exists.
We can however do our bests to protect those users by default.

SVG is wonderful, I've done tonnes of stuff with SVG. I was playing
with SVG in IE back when Adobe was shipping a plugin to render it
before they bought Macromedia. I built an iOS mapping web app using
SVG but various versions of IE and at the time all versions of Android
didn't support SVG so I ended up building a toolchain to render PNG's
to do side by side with the SVG. I've been waiting for SVG to come to
the fore for a while now. But this isn't about Joomla! working out how
to support SVG.

What you don't get is that we're out there trying to protect those who
don't get it, who don't understand and who can't work out if in fact
their document is malicious or not. Their version of IE doesn't
understand SVG, it'll likely think it's a HTML document. And in a
browser that does understand SVG it looks like an SVG, you can't see
the payload. But in the target browser with the vulnerability they
just got attacked and likely lead on to a series of other attacks.

And that's what we're trying to protect against with this code.

Cheers,

Sam Moffatt
http://pasamio.id.au

On Sun, Apr 22, 2012 at 2:35 PM, David White <da...@netriver.co.uk> wrote:
> Thank you for your reply, Sam,
>
> What you say is true but it's not quite against treating different file
> types differently. By all means check that GIFs, PNGs and SVGs don't contain
> what they shouldn't. Check them all. But do it intelligently. Clearly the
> rules for binary files (must contain nothing that looks like XML) is
> different from SVGs (disallow Javascript and external references).
>
> SVGs are ideal for mobile, for retina displays, desktop PCs. They are used
> by a number of sites including Google analytics. Even IE supports them. It's
> time Joomla worked out how to support them, I think.
>
> -David.
>
>
> On Sunday, 22 April 2012 20:02:18 UTC+1, Samuel Moffatt wrote:
>>
>> We're inspecting all uploads regardless of where they come from or
>> what they say they are because by definition they're not what they're
>> pretending to be.
>>
>> Cheers,
>>
>> Sam Moffatt
>> http://pasamio.id.au
>>
>> On Fri, Feb 3, 2012 at 4:20 AM, David White <da...@netriver.co.uk> wrote:
>> > So if we're inspecting binary formats for this sort of attack, does
>> > that preclude treating SVG differently?
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Joomla! CMS Development" group.

>> > To post to this group, send an email to joomla-...@googlegroups.com.

>> > To unsubscribe from this group, send email to

>> > joomla-dev-cm...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/naDdCqZ6r0wJ.
>
> To post to this group, send an email to joomla-...@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cm...@googlegroups.com.

[David White]

Hi Sam,

First of all, I am grateful for the hard word that you guys(and gals) do in Joomla.

About the bug. I think I do understand it. afaik an IE XSS attack is where someone places HTML-like code in an image which IE, in it's wisdom, decides to treat like HTML rather than an image. This is a wrapper for Javascript which then exploits other weaknesses to achieve the aim of the hack. The risk is from the Javascript. Joomla has an effective way of blocking this by doing the same as IE and looking for HTML-like syntax. If it's found it rejects the image.

But the risk is from Javascript, not the wrapper used to confuse poor IE. This is also the case with SVG - the risk is from the Javascript. If you point IE6/7 at an SVG image without Javascript it will get confused but there's no security risk. Actually you probably want to widen the list of possible problems with SVG: the risk is also from CSS messing with your page defines.

My argument is that we should be doing these checks intelligently. You really do want SVG for their wonderful resolution-independent sharpness and small size. You really don't want users uploading anything with a script in it or CSS because that's the security risk. So, do a check for <script>, <style>, external references, and properties such as onmouseover. Also, recurse into alternative character encodings because I think you can use them to obscure scripts. Even better, have  a configurable policy to allow or not SMIL.

it's worth the effort. I've developed modules (for sites without user-generated content) that automatically inline SVGs and wrap them up in animations. Like you I developed the tool chain to render as PNGs and I'm working on a more intelligent fall-back using the SVG <switch> statement. Have a look at www.theprayerhouse.co.uk, www.netriver.co.uk, www.refresh2012.org. It would be great if this sort of module could be publicly available.

>> > To post to this group, send an email to joomla-dev-cms@googlegroups.com.

>> > To unsubscribe from this group, send email to

>> > joomla-dev-cms+unsubscribe@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/naDdCqZ6r0wJ.
>

> To post to this group, send an email to joomla-dev-cms@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-cms+unsubscribe@googlegroups.com.

[ghazal]

Hi,
I resurrect this old discussion because since then, a lot of things has changed.
IE is less and less the P. in the A. it was. Edge is on the horizon.
And we (I) use more and more of the .svg format, it being sometimes a simple solution to responsive cases.

I checked today on j!3.4.2 dev, and, well, it is still an "unauthorized" format when trying  to upload an svg image via the media manager.
Or, if uploaded via FTP in the "images" folder, still impossible to insert it using the media manager.

My question is :
what can we expect from the NEW media manager re .svg format ?

[romacron]

In general, svg uploads must be checked and validated against scripts
and tags?!

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.


--
Diese Nachricht ist ausschließlich für den/die beabsichtigte/n
Empfänger/in bestimmt. Sie enthält vertrauliche und gegebenenfalls
rechtlich geschützte Informationen. Sollten Sie nicht der/die
Adressat/in sein oder diese Nachricht irrtümlich erhalten haben, bitten
wir Sie freundlichst, sie an den/die Absender/in zurückzusenden und sie
einschließlich aller angefertigten Kopien zu vernichten. Die Weitergabe
und das unerlaubte Kopieren dieser Nachricht sind nicht gestattet.



This message is for the sole use of the intended recipient. It may
contain confidential and possibly privileged information. If you are not
the intended recipient or if you have received this message in error, we
kindly ask you to notify the sender and destroy these messages including
all copies thereof. Any disclosure or unauthorized copying of this
message is strictly forbidden.

[David White]

On Thursday, 4 June 2015 11:09:55 UTC+1, romacron wrote:

In general, svg uploads must be checked and validated against scripts
and tags?!

 

Definitely. We need SVG support in Joomla and uploads need to be checked against scripts. Is this likely to happen, though?

[romacron]

Perhaps over the JInput with attribute check?

[Hannes Papenberg]

I wouldn't say that that is something that JInput can do. You need a
pretty specialised piece of code and to be honest, I wouldn't try to do
this in our project, but search for a third party project that knows
what they are doing.

Hannes

[Joerg]

On Thursday, June 4, 2015 at 12:21:18 PM UTC+2, David White wrote:

Definitely. We need SVG support in Joomla and uploads need to be checked against scripts. Is this likely to happen, though?

Would something like this be sufficient?
https://github.com/cure53/DOMPurify 

[Niels Braczek]

Am 05.06.2015 um 14:57 schrieb Joerg:

> Would something like this be sufficient?
> https://github.com/cure53/DOMPurify

Not without a server-side counterpart.

Regards,
Niels

--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Nils Rückmann]

Basically you could use DOMDocument etc. to validate SVG.

[Marco Dings]

With the correct mime type settings its perectly possible to support svg's. 

The challenge is in the currently implemented "security check" which in and by itself is easy to bypass.

But that should not be the solution. By its nature SVG allows for javascript and thus XSS. See brians link https://www.hackinparis.com/slides/hip2k11/09-TheForbiddenImage.pdf

And the miriad of possible attack vectors http://heideri.ch/jso/?svg

I feel this is not an IE issue, MsEdge will bring long needed improvements to support of SVG but it will not solve the XSS problem

The detection of malicious code is difficult and unlikely watertight. 

I have not come accross a third party svg tester for malicious code, except for the https://github.com/cure53/DOMPurify mentioned by Joerg which needs further investigation.

Nicholasses suggestion to optionaly bypass the test with an option to choose to forego testing for xss scripting could be combined with an  option to disallow uploading from the frontend. 

That is with the assumption that users with backend access would already be able to wreak havoc and would not need svg to do that.

I will take this up within PLT and JSST to see what we could do to add svg support to the mediamanager.

Be like me, be Carbon free - don't print this and save a tree

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.

[Nils Rückmann]

Why not just dropping script support at all ? 99% of the people want to use SVG for scalable icons etc. and not for complex scripted mini-applications.

And of course, an SVG filter library written in PHP would be a nice standalone package within the Joomla Framework.

[Marco Dings]

that might be a viable option, but it will not be an easy feat to accomplish as there 

are many possibilities

 http://heideri.ch/jso/?svg

and if we were in a postion to drop support them we could also warn against them ;) and give options

On Saturday, 6 June 2015 03:58:01 UTC+2, Nils Rückmann wrote:

Why not just dropping script support at all ? 99% of the people want to use SVG for scalable icons etc. and not for complex scripted mini-applications.

And of course, an SVG filter library written in PHP would be a nice standalone package within the Joomla Framework.

[George Wilson]

I think the bigger risk is people contributing articles not knowing what they are doing so a warning isn't enough. You could create a whole permission level to manage who can and can't deal with them but that seems like overkill.

I think a generic block on scripts (if achievable) is the best way

If anyone uploads an SVG with scripts in though outside of media manager you should still be able to attach that to an article via media manager (I.e. Media manager blocks fresh uploads but deals with any existing svgs whether they have scripts or not)

[Robert G Mears]

I don't know whether you know about a plugin called SVG Helper.

The older version works quite well (attached) I cannot get the newer version to work.

I tend to work in code view anyway and have no problem with uploading via FTP, so adding SVGs is a non-issue. Perhaps leaving it that way reduces the risk of abuse.

Examples of SVG Helper in action can be seen here: graphic identity

There is also a downside to publishing SVGs on the web: They can be scaled to any size, big or small. Raster images, on the other hand, cannot be made larger than the posted size.

[Nils Rückmann]

The Plugin is just an SVG replacer for older browsers and does not deal with the security issues. Besides that, using superglobals (like $_COOKIE) should be a no-go.

[Robert G Mears]

I know this doesn't deal with the security issues with respects to SVGs. However, it seems restricting who can add SVGs is more the concern than whether nefarious scripts can be added to them.

Good to know that harmful scripts have to be in the SVG to begin with. The way people were talking it seemed they could be added ex post facto.

[George Wilson]

If you edit an SVG for sure you can add malicious scripts in after they are uploaded to the server. However media manager currently doesn't offer the capability to add this. So the only way it could be added in is by someone directly editing the files on the server and if someone has access to the files on your server and is adding malicious code I think your SVG's are the least of your concerns :P

I think the most important thing is screening the SVG's on upload - preferably by screening the SVG's on upload for any scripts - but worst case via a new permission level to see who can upload the SVGs

At the point where media manager allows editing SVG's (currently even Buddhima's "new" media manager doesn't allow this) then you probably need to allow more checks there as well

Kind Regards,

George

[Sergio Manzi]

I'm with you, George:

• By default reserve SVG upload/handling to super-users
• If achievable, screen SVGs for script presence (any: good or bad...)  and in case block upload.

You're a site admin needing to upload an SVG with script? Use good old FTP, cPanel file manager, or whatever else, but NOT media manager.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Michael Babker]

Sorry but the one theme in this thread I'm seeing that I don't agree with is having a new ACL level just for "Can Upload SVG".  It's almost the same to me as saying "I'll give you access to the Template Manager but you can't create new overrides within the UI even though you can manage everything else" (assuming we had that type of ACL there).

--

[Sergio Manzi]

A-B-S-O-L-U-T-E-L-Y ! :-)

On 2015-06-07 16:45, Michael Babker wrote:
> Sorry but the one theme in this thread I'm seeing that I don't agree with is having a new ACL level just for "Can Upload SVG". ....