W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: [SRI] Requiring CORS for SRI

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 7 May 2015 06:37:40 +0200
Message-ID: <CADnb78gK36WxNh_Z_4RLpOK_hxVb4wjRPTOkMZOODpC-ESwHaQ@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Tanvi Vyas <tanvi@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, May 6, 2015 at 8:42 PM, Brad Hill <hillbrad@gmail.com> wrote:
> There may be a few loopholes regarding client certificate resources or
> network topology based ambient authority, but they are really edge cases,
> and hopefully the risk of combining those scenarios with an admin who thinks
> it is legitimate to set ACAO:* for the purposes of SRI is vanishingly small.

Client certificates are considered credentials per Fetch (and therefore CORS).

The exceptions are a) firewalls and b) IP-based authentication.


> One thing the spec doesn't make clear, which I'm actually working on test
> cases for at this very moment, is what if the fetch mode was CORS, but was
> fetched with crossorigin='use-credentials'?  This doesn't seem to be
> explicitly forbidden by the spec, though there are no examples of this.  Is
> it intentional that this might be possible?  I'm not sure there is any
> security impact (the resource's contents could already be viewed if the
> checks passed) but am just curious.

If only the specification were written in terms of Fetch... But yes,
that should totally work.


-- 
https://annevankesteren.nl/
Received on Thursday, 7 May 2015 04:38:03 UTC

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