Doc: failed CORS fetch with credentials should ignore Set-Cookie response header

[Osintopsec]

The docs example at https://fetch.spec.whatwg.org/commit-snapshots/c6b3a750f811cb4f628def0313ac317d9dcec88a/#example-cors-with-credentials states that:

"If the response does not include those two headers with those values, the failure callback will be invoked and any Set-Cookie response headers will end up being ignored."

Tested the example on OS X with:

Chrome Version 71.0.3578.98 (Official Build) (64-bit)
Firefox Version 64.0 (64-bit)
Safari Version 12.0.2 (14606.3.4)

and with:

fetch("https://abc.xyz/cors-testing/cors", {credentials: "include"});
fetch("https://abc.xyz/cors-testing/cors", {credentials: "include", method: "POST"});

and found inconsistency on the way the spec is implemented on the browsers. When a simple (GET, POST, no special request headers) CORS request with credentials (cookies) fails due to not receiving any CORS headers from the server, Chrome and Firefox go ahead and accept the Set-Cookie response header from the server and sets the cookie to the browser. At the same time Safari ignores the Set-Cookie response header and does not set the cookie. (EDIT: for future reference, this was false-positive. Safari does set cookies before handling CORS if 3rd-party cookies are enabled.)

My question is: which way it should be? On a failing simple request, should the Set-Cookie response header be accepted or should it be ignored by the browser?

[annevk]

Thank you for reporting this!

The original intent was definitely that Set-Cookie should not take effect. Reading the fetch algorithm however, it seems it will take an effect as the CORS check happens after cookies are handled. This might be because we added more explicit cookie handling later on and I didn't fully consider this when it happened.

I think we should ask Chrome and Firefox to change their setup and change the algorithm to enforce the original intent. And add some tests for this to web-platform-tests.

cc @whatwg/security

[mikewest]

I don't mind changing this in theory, but it will be practically difficult to implement in Chrome given our current layering. Cookies are currently handled way down in the bowels of the network stack, before handing off to CORS-aware bits of the system: reversing that ordering would be a good deal of work.

It surprises me a bit that Safari behaves differently, given that it similarly delegates cookie handling to the network stack. Is it possible Safari's third-party cookie blocking mechanisms, and not their CORS handling, were responsible for ignoring the set-cookie header in your test @Osintopsec?

[annevk]

Yeah, I was afraid of that, but it's still rather unclean to throw after side effects for the caller have happened, if you allow me to compare a fetch with a function call.

[Osintopsec]

@annevk glad to be of help!

And @mikewest Your're absolutely right, I got a false-positive here and had "prevent cross-site tracking" on Safari enabled. Allowing them gives out similar functionality as on the other two browsers.

[mikewest]

Allowing them gives out similar functionality as on the other two browsers.

Thanks for checking, @Osintopsec!

Yeah, I was afraid of that, but it's still rather unclean to throw after side effects for the caller have happened, if you allow me to compare a fetch with a function call.

I agree that it would be good in the abstract to change browsers to reject the cookie if the request is rejected. To do so in Chrome, we'd need to do a good deal of refactoring in our network stack, and do whatever measurement work was necessary to convince ourselves that we could make this change without breaking too much.

Is there a risk here beyond the uncleanliness of the result? If not, I can think of more than a few places I'd like to clean up before coming to this issue.

[annevk]

I only see a risk if the server expects CORS to be more authoritative. But yeah, I guess we should update the standard here (in particular the example mentioned by OP) and caution servers not to expect such things.

[Osintopsec]

I only see a risk if the server expects CORS to be more authoritative.

I actually run into this while doing a pentest and thought this is some odd behaviour - eventually used it to chain a CSRF to run the victim into a XSS. Of course this behaviour (setting the cookie) is achievable by other means also, form-elements and such, but fetch needs a lot less space for the payload.

Is there anything I can help you guys with from here on?

[annevk]

@Osintopsec if you'd like you could contribute a test to https://github.com/web-platform-tests/wpt that checks the cookie gets set. And if you want you could even update the standard via a pull request.

[Osintopsec]

@annevk Having a bit of backlog here, but I'll do my best. Let's update the spec first, It's probably enough to fix the example and add a note that the cookies will be set in any case?

[annevk]

Great! Yeah, reword the sentence to make it clear Set-Cookie does have an effect despite the caller getting a network error.