Re: Comment on minutes ## With Credentials flag etc

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

Received on Wednesday, 3 February 2016 18:18:07 UTC