Re: Comment on minutes ## With Credentials flag etc

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.

If it's a security measure, could you (or someone) explain what the thread model is? The CORS spec talks about the possibility of the browser becoming a confused deputy, but it isn't clear (at least to me) how withCredentials mitigates that.

Or, is there some other motivation for this design that I'm missing?

Thanks,





> On 2 Feb 2016, at 8:02 am, Jonas Sicking <jonas@sicking.cc> wrote:
> 
> On Mon, Feb 1, 2016 at 2:55 AM, Yves Lafon <ylafon@w3.org> wrote:
>> One can find information like https://annevankesteren.nl/2012/12/cors-101
>> stating that ‘*’ is always good… it is not because of what you just said, that is also why
>> people can get confused.
> 
> I think we're both trying to say that it's safe to set for any URL
> accessible to the public internet. And that the reason that it's safe
> is because it only is honored for re requests that were made without
> cookies.
> 
>> So to make it always work, you need to echo back the origin in Access-control-allow-origin,
>> it is very easy to do, and does not require a specific module for Apache.
>> The issue is that it can lead to careless administrators using that technique
>> “to make CORS work” and lead to the same issue that led to disallowing “*” with withCredentials.
> 
> Indeed, it is quite easy to indiscriminately echo back the "Origin"
> request header in a "Access-control-allow-origin" response header.
> Thereby leaking private data.
> 
> I don't know what we could have done on the spec or client side to
> lessen that risk though.
> 
> If it is still possible to make such improvements without "breaking
> the web" I'm all ears.
> 
> If it could only have been done when we originally designed the spec
> I'm bummed that we missed that opportunity. In theory we could design
> a new cross-origin protocol which includes such improvements and let
> callers opt in to it.
> 
> However in practice I've never heard of people accidentally exposing
> undesired data due to the echoing you mention, so I doubt that it'd be
> worth designing a new protocol.
> 
> / Jonas

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 3 February 2016 02:45:30 UTC