Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SameSite cookies aren't sent on credentialed CORS requests #769

Closed
1lastBr3ath opened this issue Jun 21, 2018 · 16 comments
Closed

SameSite cookies aren't sent on credentialed CORS requests #769

1lastBr3ath opened this issue Jun 21, 2018 · 16 comments

Comments

@1lastBr3ath
Copy link

Since CORS is to enable SOP bypass, cookies are expected to be sent along as long as the request is permitted. And, CORS does have the policy to only allow credential requests.

Currently, even if a site explicitly allows credentialed CORS requests from 3rd domains, SameSite cookies aren't sent. This might break some sites if only authenticated requests are served.

Since CORS is a opt-in mechanism, it would be nice to act as the policy says. If it allows credentialed requests, SameSite cookies should be sent as well.

@annevk
Copy link
Member

annevk commented Jun 21, 2018

CORS is opt-in on the response though. This would allow timing attacks on the resource so doing this would require some new kind of opt-in, as well as a mandatory preflight.

@annevk
Copy link
Member

annevk commented Jun 21, 2018

cc @whatwg/security

@1lastBr3ath
Copy link
Author

That would mean credentials requests will always get preflighted, right?

@annevk
Copy link
Member

annevk commented Jun 22, 2018

Yes, at least those where the requester wants to enable samesite cookies.

@luh2
Copy link

luh2 commented Jul 11, 2018

I just ran into the same issue.

@annevk Not sure I understood your comments - shall this be fixed or is this supposed to be kept this way?

@annevk
Copy link
Member

annevk commented Jul 23, 2018

I suspect this will be kept this way, but this issue remains open for now as it's not as clear as it could be in the standard.

@Shahor
Copy link

Shahor commented Jan 31, 2019

Hello,

I just got bit by this and spent a lot of time understanding what the issue was :|

I use cookies to make authenticated cross domain requests from domain.com to subdomain.domain.com.

Because of SameSite: Lax I can't make my requests (that was very painful to debug >_<) even though I passed all the preflight queries properly.

I understand now the purpose of the SameSite: Lax value, but in my context it is an issue because I either:

  • Remove this option, and open myself to CSRF (although I'm working on an API this might be less of an issue but still)
  • Keep this option and can't authenticate at all :|

Is there anything you would recommend on this situation?

@arturjanc
Copy link

One possible workaround is to use two authentication cookies, one regular and one marked as SameSite. On most endpoints your authentication code would require both cookies to be present, but for requests to endpoints which expect CORS requests you could only authenticate the user with the regular, non-SameSite cookie.

@Shahor
Copy link

Shahor commented Jan 31, 2019

But then you are open the same way to CSRF attacks, aren't you 🤔 ?

@arturjanc
Copy link

Yes, the part of your site which expects to respond to CORS requests could still be vulnerable to CSRF. But requests to this part of your site will be made in cors mode so you can check the Origin header and make sure that the request is sent same-site, getting protection equivalent (or very close) to what SameSite cookies offer.

@Shahor
Copy link

Shahor commented Jan 31, 2019

Yes, I was actually going to perform those verifications in a middleware besides my cors handling, thanks to a friend's suggestion.

In that mode you can still use the one cookie version, to avoid complicating that process :)

[edit]: thank you for your help 🙇

@tmccombs
Copy link

What if there was an additional SameSite mode between none and lax, which meant that cross-site requests are allowed to send the cookie, provided that the domain of the origin is "allowed". Where "allowed" could either mean matching a whitelist specified in another cookie directive (or part of the SameSite directive), or by making a mandatory preflight to check cors headers.

@annevk
Copy link
Member

annevk commented Oct 28, 2019

@mikewest ^

@mikewest
Copy link
Member

What if there was an additional SameSite mode between none and lax, which meant that cross-site requests are allowed to send the cookie, provided that the domain of the origin is "allowed".

If you squint a bit, this is more or less what I proposed in https://tools.ietf.org/html/draft-west-cookie-samesite-firstparty. Given our experience thus far with changing SameSite's default behavior in Chromium, this kind of thing is more difficult then we expected it to be. The behavior of some browsers (thos on iOS 12 in particular) make deployments complicated. We did a bad job keeping that joint oiled, and I think it's going to be more trouble than it's worth to bend any further than we're already pushing it.

@annevk
Copy link
Member

annevk commented Mar 11, 2021

Closing this as by design. This will be further clarified in the specification once #693 is fixed.

@annevk annevk closed this as completed Mar 11, 2021
@tmccombs
Copy link

If you squint a bit, this is more or less what I proposed in https://tools.ietf.org/html/draft-west-cookie-samesite-firstparty.

Kind of. Except that it depends on "First party sets" which can only be defined once for the entire site. Whereas my proposal allows more granular control over which domains are allowed to make requests containing each cookie.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants