Setting samesite cookies when not same site context

[aliams]

What happens when a page tries to set a samesite cookie when we are not in a samesite context? For instance, a top-level a.com has an iframe to b.com and b.com tries to set a cookie with the samesite attribute. It sounds like we would want the cookie to not be writeable since it's not readable in that case.

cc @mikewest

[fmarier]

In Firefox, we prevent same-site cookies from being set in a third-party context.

[johnwilander]

I vaguely remember discussions on this, i.e. whether the whole cookie should be dropped or just the SameSite attribute. Anyone on this thread who remembers? (Part of what I remember is that Mozilla changed their mind.)

[ericlaw1979]

Blocking SameSite cookie creation in cross-origin POST contexts means that an OAuth cookie that is set as a result from a POST from the auth provider site will fail. This seems undesirable.

[mikewest]

I think it's pretty clear that we ought to be blocking the creation of SameSite={Lax,Strict} cookies in cross-site subresource requests. Firefox does that today, and Chrome just landed a patch to do the same.

Navigations are more interesting. We send SameSite=Lax cookies along with "safe" HTTP methods (e.g. GET, but not POST). Chrome's implementation applies the same restriction to SameSite=Lax creation. I assumed that Firefox's implementation did the same, but @ericlaw1979 suggests in https://bugs.chromium.org/p/chromium/issues/detail?id=837412#c18 that it doesn't. That seems strange to me, though perhaps justifiable given the use case Eric's pointing to.

I think I could live with a world in which top-level navigations (regardless of method) are empowered to create SameSite cookies (but keep the rules around sending them as they are). Would that address your concerns, Eric? Does it open us up to attacks I'm not thinking about?

/cc @mozmark @morlovich

[ericlaw1979]

I've built a reduced repro for this scenario at https://webdbg.com/test/cookie/samesite/post.aspx .

Firefox Nightly ignores the attempt to set the SameSite cookie for the cross-origin image, but permits the cookie to be set during the form post.

I believe that the proposed fix (matching Firefox) unblocks the OAuth scenario regression we've found, although I do wonder about the notion that a context shouldn't be able to set cookies that it, itself, cannot read (e.g. a page can currently set secure or path= to which the context itself does not belong).

[mikewest]

Firefox Nightly ignores the attempt to set the SameSite cookie for the cross-origin image, but permits the cookie to be set during the form post.

Yeah, that does seem to be Firefox's behavior. I'm curious about how they landed on that, and how exactly they're determining whether to allow the cookie to be set. Are they just ignoring the "safe method" bit? Do nested navigations work as well? @mozmark, WDYT?

I do wonder about the notion that a context shouldn't be able to set cookies that it, itself, cannot read (e.g. a page can currently set secure or path= to which the context itself does not belong).

You're right about path, but a page cannot set secure unless it's capable of reading secure cookies by virtue of being delivered over secure transport.

[ericlaw1979]

a page cannot set secure unless it's capable of reading secure cookies by virtue of
being delivered over secure transport.

Ah, I'd forgotten that this was added in leave-secure-cookies-alone and further confused myself by running my test case in a Edge Spartan window (IE and old Edge never implemented that update).

[mikewest]

Assuming @mozmark doesn't object in the near future, I'd suggest running with the proposal to remove the "safe" method check for storage. I'll put up a PR at some point soonish.

[mikewest]

PR in #800.