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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 10 Apr 2013 09:51:09 +0100
Message-ID: <CADnb78iz-Bf1uno+kdhVC6tptAgmOLCdzfDtwXg1C9bvamy5pQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
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 3:51 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Wed, Apr 10, 2013 at 1:25 AM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>> 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.
> It seems to me that with our current restrictions on SVG images, Web
> developers can safely host SVG images in a "sandbox" domain, and safely use
> those images cross-origin from the main site.
> If we enable external loads for SVG images, the examples of trickery in
> https://bugzilla.mozilla.org/show_bug.cgi?id=628747#c0 are enabled against
> such sites.
> So I still don't see any painless solution here.

If we accept the need for a sandbox domain, same-origin loads becomes
an option I think. And actually, even in the face of an open redirect
you could fail flat the moment the target URL becomes cross-origin and
not fetch it. Several APIs on the platform have a request mode of
same-origin  (different from tainted cross-origin, which will fetch)
with an opt in availability for CORS.

Received on Wednesday, 10 April 2013 08:51:39 UTC

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