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

Re: Improving CORS security

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 10 May 2017 08:27:20 -0700
Message-ID: <CAPfop_3OFiHFeqHEJxO4iuiRyisk_rLS2gCpkOjjfKooCwmh3Q@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, James Kettle <james.kettle@portswigger.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>

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.


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:28:21 UTC

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