Allow setting cookie header in credential-less CORS requests

[sicking]

I'm guessing that the reason we're forbidding the cookie header from being set for cross-origin requests is to prevent session-pinning attacks.

However is there a reason we're forbidding setting the cookie header for requests whose "credentials mode" is "omit" or "same-origin".

Allowing setting the cookie headers on such requests could be useful to allow a website A to make requests to websites B using A's credentials to B rather than the user's credentials to B.

Note that I'm not suggesting that we make cookie a "simple header". That would be bad for the same reason that making authorization a "simple header" would be bad. I.e. that it could allow distributed brute-forcing credentials.

[annevk]

Well, one reason is that the network layer adds the cookies to the request. If the API layer can add cookies too, that would somehow need to be reconciled. The way that works with Authorization is that if the API layer sets it, the network layer basically doesn't set it.

Another reason is that we decided not to expose cookies in XMLHttpRequest based on discussion with @abarth et al.

There does seem to be some revived interest in doing all kinds of things with cookies, e.g., https://github.com/bsittler/async-cookies-api, so maybe we should reconsider the interactions Fetch has with cookies.

@mikewest, thoughts?

[sicking]

Note that i'm only talking about requests whose "credentials mode" is "omit" or "same-origin". For these requests neither cookie nor authorization headers are added by the network layer when the request is going cross-site.

For same-site requests we would indeed need to define how reconcile headers set through API with headers coming from the network.

And yeah, we should probably also look at exposing cookies in the response. Or at least enable websites to make to make additional requests using such cookies.

[mikewest]

Is there a use-case driving this request? As-is, it seems like passing information between sites can be pretty cleanly done with GET parameters or POSTed bodies. Adding cookies in could certainly cause issues, and I'm not sure it's a good idea to give evil.com control over cookies in requests to bank.com (session-fixation to the site, it's attack surface that hasn't yet been exposed cross-origin).

If there's something interesting driving the request, then let's chat about it. If not, I'd prefer to leave well-enough alone.

[sicking]

@mikewest note that i'm only talking about requests whose "credentials mode" is "omit" or "same-origin". For these requests neither cookie nor authorization headers are added by the network layer when the request is going cross-site, and if cookie headers are received in the response they are ignored by the client.

So I don't think this would enable session-pinning.

The use case is the one that Tim is worrying about over in w3ctag/design-reviews#76, best I can tell.

[mikewest]

@sicking: I understand the restriction, and I agree that it would enable session fixation only in cases where the site was doing something strange (tying sessions to IP addresses, etc).

I didn't explain the "attack surface" bit clearly enough, and I think it's the more important point: sites today assume that they have complete control over cookies. This falls down, of course, with registrable domain excitement, but would be much worse if sites needed to deal with malicious third-parties sending constructed cookie payloads. Of course they ought to be protecting themselves because never trust the client, but I suspect that this would cause some issues. It also might allow brute-forcing of credential information/session ids/etc. in a way that isn't possible today.

I skimmed the thread you pointed to, and Tim, et al. raise a number of questions. It's not at all clear to me that this addresses any of them. :) How does enabling a website to send arbitrary cookies to a third-party solve the problem of not knowing whether or not credentials ought to be sent to an endpoint?

[domenic]

I didn't explain the "attack surface" bit clearly enough, and I think it's the more important point

I'm still having trouble understanding the attack, despite your explanation here. Isn't this just exactly what sites could already do, by asking their server-side code to send requests with constructed cookie payloads? Is the attack the idea that constructed cookie payloads + ambient authority is unexpected (even though constructed cookie payloads is totally doable already)?

[mikewest]

I think the scale is substantially different: my server can hammer yours for a few hours before you get a firewall alert and block my IP address. It's substantially more difficult to block a few hundred browsers from doing the same.

shrug "curl can do it!" doesn't seem like a good reason to add functionality.

[sicking]

Apart from the curl argument, as mentioned in the initial comment, cookie wouldn't be a "simple header". So websites would still have to explicitly opt-in to enabling third parties to send a cookie header, the same way that they currently can opt in to enabling third to send a authorization header.

[mikewest]

Ah, I missed that. If we preflight the request, then I think you've taken care of the security concerns.

I still don't understand the use case, though. :)

[annevk]

I'm inclined to close this @sicking. Any remaining reasons we should do this?

[sicking]

The reason to do this is that it'll allow us to support a bigger set of HTTP semantics. I.e. we should do this for the same reason that we added Access-Control-Allow-Headers. We didn't have specific requests from authors for that, but it seemed like a good idea to support a larger set of HTTP semantics. Since then we've seen lots of people use it confirming that it was a good idea to add the support.

I think disabling cookies means disabling a pretty big and important part of http. That seems like a bad idea.

[annevk]

I'm closing this since although I somewhat agree with the theoretical goal, it's hard to do anything here without interest from all the implementers.