W3C home > Mailing lists > Public > www-tag@w3.org > February 2016

Re: Comment on minutes ## With Credentials flag etc

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 4 Feb 2016 09:40:19 +1100
Cc: Yves Lafon <ylafon@w3.org>, Tim Berners-Lee <timbl@w3.org>, Public TAG List <www-tag@w3.org>
Message-Id: <FACE298C-62D3-4C7F-BE6A-AB20EE89E81E@mnot.net>
To: Jonas Sicking <jonas@sicking.cc>
Thanks, Jonas - that's (again) very helpful.

One thing this brings to mind is the current discussion on an origin-level preflight:
  https://github.com/whatwg/fetch/issues/210

If such a thing were defined, it'd provide a more reasonable way for sites to opt into credentials (if the mechanism allows that).

Cheers,


> On 4 Feb 2016, at 5:17 am, Jonas Sicking <jonas@sicking.cc> wrote:
> 
> On Tue, Feb 2, 2016 at 6:44 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> Hi Jonas,
>> 
>> Thanks for all of the context, it's most helpful.
>> 
>> Could you explain a bit more about how withCredentials fits in?
>> 
>> AIUI, it works with Access-Control-Allow-Credentials (ignoring the interaction with Access-Control-Allow-Origin for now);
>> 
>> 1) If both are false, the check succeeds and credentials aren't used.
>> 2) If both are true, the check succeeds and credentials are used.
>> 3) If withCredentials is false and ACAC is true, the check succeeds and credentials aren't used.
>> 4) If withCredentials is true and ACAC is false, the check fails.
>> 
>> ... as per <https://www.w3.org/TR/cors/#resource-sharing-check>.
>> 
>> If that's a correct interpretation, the interesting one here is #3. What's not clear to me is whether this is an optimisation or if it's intended to prevent some sort of attack or information leakage.
>> 
>> If it's an optimisation (to avoid the round trip to discover ACAC on what was a simple request), couldn't the browser take the presence of ACAC on the response as a signal that it should have included credentials, and reissue the request? Of course it's not optimal, but it would remove the *need* to set withCredentials to get interoperability.
> 
> It is not to mitigate a threat, at least not primarily.
> 
> It is to avoid having to issue two requests. I think calling it an
> "optimization" is understating it a bit.
> 
> Not only would issuing two requests many times likely be so slow that
> people would likely opt to use other solutions, such as JSONP.
> 
> The other problem is that for requests that have side effects, issuing
> the request twice could of course be problematic. This applies to GET
> requests as well unfortunately since unfortunately they in practice
> often do have side effects.
> 
> It's not clear to me how big this problem would be in practice though.
> For request that has side effects and that uses cookies, it is likely
> common that those cookies are used for authentication and thus issuing
> the request without cookies would result in a denied request and no
> side effects (maybe other than logging an error).
> 
> So in that case issuing two requests, where the first one is without
> credentials, would be fine.
> 
> But if cookies are used for other things than authentication, then
> issuing the request twice seems like it could easily be a problem.
> 
> For that reason, I think re-issuing the request when an "ACAC: true"
> is returned would be bad (not to mention likely not web compatible at
> this point).
> 
> All of this was debated while we did the initial CORS design.
> 
> What I don't remember debating, and which might work, would be to add
> a different header which explicitly has the meaning "if this request
> was issued without credentials, please re-issue this request with
> credentials".
> 
> Then leave it up to the server administrator to make sure that the
> initial, credential-less, request doesn't create side effects.
> 
> 
> I could see some privacy concerns with this though. Say that website A
> wants to use some REST API which website B provides. Currently website
> A can do this without exposing to B that the user is using website A.
> Simply issue CORS requests with .withCredentials is set to false.
> 
> If we add a "please re-issue with credentials" header, then that means
> that website B can now figure out the users identity, assuming the
> user is logged in with B, by asking the request to be re-issued.
> 
> Again, I don't know how big of a problem this would be.
> 
> 
> I'm also not sure how popular this feature would be with developers. I
> suspect most of them would prefer to use libraries which enable them
> to set .withCredentials to true, rather than pay the cost of issuing
> two requests.
> 
> / Jonas

--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 3 February 2016 22:40:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 February 2016 22:40:55 UTC