W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2013

Re: [filter-effects][css-masking] Move security model for resources to CSP

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 10 Apr 2013 01:25:00 +1200
Message-ID: <CAOp6jLZtuSjAOq7O=sLy6WDU2KHTx0-9P0tF7tY_vLmHyUe_8g@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Daniel Holbert <dholbert@mozilla.com>
On Wed, Apr 10, 2013 at 1:15 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Apr 9, 2013 at 1:24 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> > Basically, many Web sites accept uploaded images and expect those images
> to
> > be self-contained and not be able to trigger further loads. Violating
> this
> > assumption creates several kinds of potential problems. See
> > https://bugzilla.mozilla.org/show_bug.cgi?id=628747.
> But this also requires websites to enable support for SVG in the first
> place. And contrary to bitmap image formats, SVG resources must be
> labeled with a correct MIME type. It seems somewhat unlikely that both
> of those would be in place without the site also knowing about what
> SVG can do.

On the contrary, I find it very plausible that Web developers might add SVG
as a supported format without knowing what SVG can do :-).

Furthermore, people could be tricked into loading the SVG
> resource directly! (It's not something you want to host same-origin
> for instance, whereas hosting a PNG same-origin is always fine.)

That is a good point. I think we didn't consider that, and that may mean
it's just not safe to host uploaded SVG images at all currently, at least
not without severe sanitization. Needs more thought than I can give it

> AFAIK the only major difference in the way SVG images and SVG external
> > resource documents are processed is that SVG images can't do external
> loads.
> > (We disable scripting and enable animation in both.) That's a pretty big
> > difference though!
> >
> > We disable native theming in SVG images but not SVG external resource
> > documents, so that authors can't get the pixel data of native themes, but
> > that's obscure and probably unimportant.
> Maybe loading subresources should be an option for the API initiating
> the fetch so they can explicitly opt into the lifting restrictions we
> have put in place (whether we should have those restrictions in the
> first place; not sure).

That's an option, but again it doesn't escape the need to make breaking
spec changes to resolve the existing requirements.

We need to think about whether it's possible and a good idea to remove the
no-external-loads restriction on SVG images. Don't want to be hasty and
expose a security issue :-).

q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Tuesday, 9 April 2013 13:25:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:32 UTC