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
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.
>
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
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:
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.
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.
Cheers,
Sam Moffatt
http://pasamio.id.au
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
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
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
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?
>
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.
It's time Joomla worked out how to support them, I think.
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.
>> > To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > 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
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?
Be like me, be Carbon free - don't print this and save a tree |
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.
--
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.
--