- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 10 Apr 2013 09:51:09 +0100
- 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. -- http://annevankesteren.nl/
Received on Wednesday, 10 April 2013 08:51:39 UTC