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

Re: [CSP] SVG-in-img implementation difference

From: Mike West <mkwst@google.com>
Date: Wed, 23 Apr 2014 15:24:25 +0200
Message-ID: <CAKXHy=ectspe+spnMCvut03uvZTKuCdN5b5_dq2+bKqKpsSfZA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Ted Mielczarek <ted@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Apr 23, 2014 at 3:19 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Apr 23, 2014 at 3:01 PM, Mike West <mkwst@google.com> wrote:
> > Ted's initial question was, as I understand it, "Should images loaded
> inside
> > an SVG document loaded as an image be subject to the policy served with
> the
> > SVG document itself, or to the policy from the page that loaded the SVG
> > document as an image."
> >
> > My answer is that the page's policy should apply: if the SVG document
> wants
> > to load an image, it should only be allowed to do so if the page could
> load
> > an image.
>
> Right, and my answer is that CSP should not even come into play in the
> scenario where SVG is used as image as it should be as safe as any
> other content referenced from <img>.
>

Images are, generally, relatively safe. In the absence of a large hole in
image processing code, the 'img-src' directive is much more practically
useful for preventing defacement than for preventing pwnage.

Given that, consider two scenarios:

A. 'https://example.com/image.jpg' which redirects to '
https://evil.com/image.jpg'
B. 'https://example.com/image.svg' which loads 'https://evil.com/image.jpg'

If we disallow A, why would we allow B?

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 23 April 2014 13:25:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC