search

plone / volto

React-based frontend for the Plone Content Management System
https://demo.plone.org/
MIT License
472 stars 639 forks source link

Authentication cookie and `SameSite` property #5182

Open erral opened 1 year ago

erral commented 1 year ago

Describe the bug

When logging in in a development Volto (current master), Firefox 117 reports the following in the development console:

Cookie “auth_token” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

In a recent project we have been having issues with the auth_token regarding this SameSite behavior. We are setting the auth_token cookie through Plone backend, because we validate users externally in Plone backend, set the cookie to the user, and then redirect to Volto.

In some cases we have seen Chrome removing or marking cookies as invalid.

We may need to check how the auth_token is set in Volto and check whether we need to set the SameSite attribute to something (at least be explicit and set it to Lax if I understand correctly this behavior)

abhinaisai2002 commented 1 year ago

If we set the cookies with samesite option as none, the browser is going to show a warning and doesnot set the cookies in the client, we need to put extra option as Secure while setting the cookies in the backend, making sure they are shared over https,

Lax makes us to send the cookies at top level get request in another origin. I think it does not satisfy our need to send cross oigin requests

erral commented 1 year ago

If we set the cookies with samesite option as none, the browser is going to show a warning and doesnot set the cookies in the client, we need to put extra option as Secure while setting the cookies in the backend, making sure they are shared over https,

I think we can't afford that, because we should make no assumptions on the way that Volto will be deployed by the developer.

Lax makes us to send the cookies at top level get request in another origin. I think it does not satisfy our need to send cross oigin requests

Why do we need to send cross origin requests? In all recommended and documented deployment scenarios, Volto and the backend are configured in the same domain (indeed we document explicitly that this is to avoid CORS issues), either using the ++api++ seamless mode or deploying the backend in /api right?

abhinaisai2002 commented 1 year ago

Yeah, there is no use of cross-origin requests in here, we can use samesite=Lax, we need to set this property in the backend

erral commented 1 year ago

Yeah, there is no use of cross-origin requests in here, we can use samesite=Lax, we need to set this property in the backend

The point is that the auth_token cookie is set in the front-end.

abhinaisai2002 commented 1 year ago

@erral Oh, I recently joined in this organization, I have no idea about it. But upto my knowledge, setting the cookies in the frontend expose more vulnerability to cross scripting attacks, it is better to implement in the backend

erral commented 1 year ago

@erral Oh, I recently joined in this organization, I have no idea about it. But upto my knowledge, setting the cookies in the frontend expose more vulnerability to cross scripting attacks, it is better to implement in the backend

OK, but that's another issue. That's not how the Plone REST API and Volto work right now. It would mean to change the way.