- From: Mike West <mkwst@google.com>
- Date: Wed, 10 May 2017 17:36:57 +0200
- 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>
- Message-ID: <CAKXHy=ff+wxi3+EP1xh7HExH_tpTMNroA_sGTisN9-HpBBBqVg@mail.gmail.com>
On Wed, May 10, 2017 at 5:27 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > 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 credentials? > > 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