- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 29 May 2013 12:27:28 -0700
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, Anne van Kesteren <annevk@annevk.nl>, Bjoern Hoehrmann <derhoermi@gmx.net>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Daniel Holbert <dholbert@mozilla.com>, Philip Rogers <pdr@google.com>
On Wed, May 29, 2013 at 11:48 AM, Dirk Schulze <dschulze@adobe.com> wrote: > On Apr 10, 2013, at 2:18 AM, Robert O'Callahan <robert@ocallahan.org> wrote: >> On Wed, Apr 10, 2013 at 8:51 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> 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. >> >> So we need to turn all kinds of external loads into CORS same-origin loads? >> >> That sounds like it would work, but be quite invasive to spec and implement. > > To recapitulate: > > This threat currently focuses on SVGs as image resources and if there are ways to let an SVG image load further resources. An initial test for <img> and CSS Images actually shows that Firefox and Chrome block any external resources of an SVG image right away - independent if the resource has the same origin or not. The bug reports on Chrome [1] and Firefox [2] and this thread actually confirm that. > > Maybe CSS and SVG should specify exactly that: No load of any external resources of an SVG file loaded as image. Exclusions of the restrictions can be specified later after more investigations. > > Is that something we can agree initially? I'm happy with whatever roc and Anne are happy with. ^_^ ~TJ
Received on Wednesday, 29 May 2013 19:28:18 UTC