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

Re: Improving CORS security

From: Mike West <mkwst@google.com>
Date: Wed, 10 May 2017 17:36:57 +0200
Message-ID: <CAKXHy=ff+wxi3+EP1xh7HExH_tpTMNroA_sGTisN9-HpBBBqVg@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, James Kettle <james.kettle@portswigger.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, May 10, 2017 at 5:27 PM, Devdatta Akhawe <dev.akhawe@gmail.com>

> Hi
> That allow-credentials works with null is actually pretty useful to and
> lets us more easily adopt CSP/Iframe sandbox. I am pretty strongly against
> adding a  new limitation: first because backwards compatibility is
> important and second because I think we should do more to encourage use of
> sandbox. IMO, in terms of impact, trusting null is the same bug as
> reflecting the origin header in Access-control-allow-origin, which is also
> very common on the web.

You probably know this, but for clarity, the problem James is pointing out
is that sandboxed frames all look the same. `https://evil.com` in a sandbox
sends the same `Origin` header as `https://yay.com` in a sandbox. You might
trust the latter, but not the former, but CORS gives you no mechanism of
distinguishing between the two.

Since `null` is basically `*` for sandboxed frames, applying similar
restrictions with regard to credentials seems like it might be a reasonable
thing to do.

Is Dropbox making CORS requests from sandboxed frames that require

> Regards
> Dev
> On 10 May 2017 at 04:50, Mike West <mkwst@google.com> wrote:
>> On Wed, May 10, 2017 at 1:01 PM, Anne van Kesteren <annevk@annevk.nl>
>> wrote:
>>> On Wed, May 10, 2017 at 12:57 PM, Mike West <mkwst@google.com> wrote:
>>> > I agree, but it's not clear to me that that would be fatal, since
>>> browsers
>>> > that support CSP already have code to deal with this kind of wildcard
>>> > syntax.
>>> Dare I ask whether that is fully interoperable?
>> Yup. 100%, probably. Maybe even 101%, because user agents wouldn't ship
>> things that didn't comply to the spec!
>> *cough*
>>> Last I checked this
>>> was defined with some ABNF which didn't inspire confidence. Also,
>>> would this result in http://example/ matching HTTP://EXAMPLE/ whereas
>>> it does not now?
>> I believe that the combination of the parsing and matching algorithms in
>> the CSP spec are pretty solid (but, really, getting more eyes on the
>> document would be better). But my point was less "Hey, let's reuse CSP!"
>> and more "Wildcards are a problem that's totally possible to solve if we
>> decide that we want to solve it."
>> -mike
Received on Wednesday, 10 May 2017 15:37:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:01 UTC