Cookie from cross-site without SameSite attribute

[danielfoxp2]

Summary

Hello people.

Chrome team are making changes in its cookie policy and it seems that it will affect Couchdb. As I didn't see this subject being discussed here I thought that would be good to start the discussion before Chrome breaks CouchDB.

I'm developing an application that uses CouchDB and I'm using Cookie Authentication to allow my users to do things. Because of my architecture decisions my app demands CORS use.

There is where new Chrome policy kicks in. Everytime I make a call to Couch I receive the warning:

A cookie associated with a cross-site resource at https://my.cool.domain/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

So, I'm assuming that you are not aware of this yet and if I'm wrong, please accept my appologies and my only intention is bring this subject up in order to make CouchDB continue to work properly.

p.s. I removed the issue template because I think that the summary is really self explanatory and therefore the remaining sections would only add duplicated info. If I did wrong, please let me know and I'll fix it.

[ImATechnophile]

This console warning is not an error or an actual problem — Chrome is just spreading the word about this new standard to increase developer adoption.

The release date for a fix is 02/04/2020 per: https://www.chromium.org/updates/same-site

I solved the same problem by adding in the response header

response.setHeader("Set-Cookie", "HttpOnly;Secure;SameSite=Strict");

SameSite prevents the browser from sending the cookie along with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are Lax or Strict.

Please refer to this before applying any option.

Hope this helps you.

[dbashyal]

This console warning is not an error or an actual problem — Chrome is just spreading the word about this new standard to increase developer adoption.

The release date for a fix is 02/04/2020 per: https://www.chromium.org/updates/same-site

I solved the same problem by adding in the response header

response.setHeader("Set-Cookie", "HttpOnly;Secure;SameSite=Strict");

SameSite prevents the browser from sending the cookie along with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are Lax or Strict.

Please refer to this before applying any option.

Hope this helps you.

@ImATechnophile You missed link - https://stackoverflow.com/a/58320564/534525

[danielfoxp2]

This console warning is not an error or an actual problem — Chrome is just spreading the word about this new standard to increase developer adoption.

I know it is not an error or problem, but since it is the couch itself that sets the cookie I thought that should be the couch the one who needs to set the same site attribute. Am I wrong about this?

I'm asking because I understand very little about this subject.

Thanks.

[AdrianoFerrari]

I'm also confused and concerned by this. If I'm reading this correctly, won't this break authentication for CouchDB in February for (at least) some users?

Seems to me that, while devs might be able to fix this on their end (as per stackoverflow link), it should be dealt with properly on CouchDB side.

Let me know if I've misunderstood.

[willholley]

I think the implication is that it will break CORS support, as cookies must specify SameSite=None; Secure to continue working in Chrome. The default behaviour shouldn't break most CouchDB use cases but we could do better by setting SameSite=Strict.

We may also need a way to handle legacy clients, which is a bit messy. @rnewson it looks like you added the SameSite support to MochiWeb. Do you have more considered thoughts on this?

[ErikVerheul]

Question: Will there be a CouchDB release 2.3.2 or 2.3.1.1 with the SameSite change? I have a CouchDB instance in the cloud and while developing I have my client software local on my PC on a different domain. I use cookie authentication. Executing that software triggers the Chrome warning.

[willholley]

@ErikVerheul it's not my decision but the dev team are very focused on getting a 3.0 release done so I wouldn't expect any fix to be backported before that. FWIW I expect 2.x -> 3.x to be a far less disruptive upgrade than the 1.x -> 2.x upgrade for most users.

[willholley]

A potentially minimal change would be to allow the SameSite value to be configured via the CouchDB config. If not set, do not include the attribute in the session cookie.

[ashish9718]

how can i solve this problem in android integrating paytm api in app

[komorebi-san]

@ImATechnophile

Sorry to ask, but where do you add the line:

response.setHeader("Set-Cookie", "HttpOnly;Secure;SameSite=Strict");

[willholley]

@komorebi-san in CouchDB 3 you can set the SameSite value in your cluster configuration (usually the local.ini file) as per https://docs.couchdb.org/en/latest/config/auth.html#couch_httpd_auth/same_site.

[komorebi-san]

@willholley

I have upgraded from 2.3.1 to 3.0.0. and added as per:

https://docs.couchdb.org/en/latest/config/auth.html#couch_httpd_auth/same_site

However, I am still blocked by Google Chrome.

A cookie associated with a cross-site resource at https://xx.xx.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

[willholley]

what are you trying to do? The only situation I know of when you would be blocked is when using CORS, in which case you need to remove SameSite protections using SameSite=None and use HTTPS.

[komorebi-san]

@willholley

My apologies, I set "same_site" in [chttp] instead of [couch_httpd_auth]. Thanks!

[wohali]

I think this is now resolved by #2452 . If not, please let us know.

[mqtik]

What about nginx?

I can't seem to make authorization by cookie to work. Can't really say if it's for nginx.

It sets the cookie on POST, and subsequent request are not followed by a cookie header.

Tried to set same_site on local.ini but that broke the auth on Fauxton (started to happen the same that happens on my site). POST works fine, GET doesn't have Cookie on the header. I had to take the attribute out because I needed to log in again.

Any help it's greatly appreciated.

[wohali]

If you are putting CouchDB behind nginx, this isn't a CouchDB bug, but a usage issue.

Please open a new discussion here.

[komorebi-san]

@mqtik What browser are you using?

[SinanGabel]

This works (solution in first note on page):

https://github.com/apache/couchdb/discussions/3012

On Sat, 5 Sep 2020 at 07:14, Matías notifications@github.com wrote:

What about nginx?

I can't seem to make authorization by cookie to work. Can't really say if it's for nginx.

[image: image] https://user-images.githubusercontent.com/42002579/92298234-11cda000-ef1d-11ea-92a4-ea9b01102fd0.png

It sets the cookie on POST, and subsequent request are not followed by a cookie header.

Tried to set same_site on local.ini but that broke the auth on Fauxton (started to happen the same that happens on my site). POST works fine, GET doesn't have Cookie on the header. I had to take the attribute out because I needed to log in again.

Any help it's greatly appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apache/couchdb/issues/2221#issuecomment-687552502, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKTZUTA4PWKNP4WD5M4JJTSEHCJVANCNFSM4I5B5FIQ .

[mqtik]

Fixed. Turns out, Cookie must be included when allowing headers on nginx, and also pass headers/requests to couchDB.

[avtarnanrey]

I'm using HAProxy and tried few things but did not work so ended up adding following temporary solution. If anybody finds a proper solution. Please let me know.

http-response replace-header Set-Cookie ^((?:.(?!\ [Ss]ecure))*)$ \1;\ Secure