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

On Apr 9, 2013, at 6:25 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> 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 tonight.
> 
> > 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 :-).

I actually just was reminded on one possible security flaw with SVG image and external references.

Take an account at Twitter or Facebook. For both it is not possible to upload an SVG as image. One reason could be the following scenario:
* I upload an SVG file and add a image reference in the SVG file <image xlink:href=…"/>
* This reference has a different origin where the image (e.g a PNG) is hosted
* The sever hosting this image now can log how often the image was loaded and can make assumptions how often the user profile was clicked on this portal.

Greetings,
Dirk

> 
> Rob
> -- 
> 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:47:45 UTC