Cannot login to local dev server

[Stimim]

How to Reproduce

• npm run dev to start a dev server.
• Open http://localhost:3000/article/1fi7dla9wtwjn with Google Chrome or Safari.
• Click the Login button in top right corner.
  • You should be redirected to https://cofacts.hacktabl.org/article/1fi7dla9wtwjn
• Go back to http://localhost:3000/article/1fi7dla9wtwjn
• What is expected: You should be logged in, and your account should be shown in top right corner.
• What actually happened: Not logged in, Login button is still shown in top right corner.

Additional Info

In both browser, there is no cookie from cofacts domain.

Google Chrome

Found the following message in developer console:

A cookie associated with a cross-site resource at
http://cofacts-api.hacktabl.org/ 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.

Safari

Found the following message in javascript console:

[Error] The source list for Content Security Policy directive 'script-src'
contains an invalid source: ''report-sample''. It will be ignored.

[MrOrz]

https://www.chromium.org/updates/same-site

1. rumors-api has not add SameSite: none; secure to its cookie
2. Google says "We have begun enforcing the new behavior for Chrome 80 stable, just not for 100% of users. ". This means that some users are already blocked from Cofacts due to this issue, while others can still proceed with a warning message:

A cookie associated with a cross-site resource at http://cofacts-api.g0v.tw/ 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.

The message is different from the one @Stimim received. The difference is marked italic, stating that the browser has not blocked the cookie yet; while Stimim's browser is chosen by Google and blocked cookies according to SameSite rules.

Impact range

For users with a browser that enforces same-site, they will have issue when

• visiting http://localhost:3000: requests to https://cofacts-api.hacktabl.org will have no cookie set
• visiting https://dev.cofacts.org: requests to https://cofacts-api.hacktabl.org will have no cookie set
• visiting https://cofacts.org : requests to https://cofacts-api.g0v.tw will have no cookie set

However, cofacts.g0v.tw and cofacts-api.g0v.tw are considered same-site, cofacts.hacktabl.org and cofacts-api.hacktabl.org are also considered same-site, thus these are already "same-site" and can still work under the default SameSite: Lax behavior.

References

Definition of "same-site": https://web.dev/samesite-cookies-explained/#explicitly-state-cookie-usage-with-the-samesite-attribute

Mitigation

There are 3 ways to mitigate the same-site change:

Method 1: relax samesite

Since rumors-api acts as an authentication service, its cookie should be sent in third party context. We should set SameSite: none; secure on the login cookies set by rumors-api.

After enforcing samesite on rumors-api, we may encounter issue developing using http://localhost:3000. Need to investigate workarounds, or provide documentation for devs to setup https on localhost.

References

• Auth0's mitigation
• Microsoft's mitigation
• Heroku's post
• Chromium SameSite latest updates

Method 2: use same-site APIs whenever possible

Another way to mitigate is to keep API endpoints always same-site, so that same-site cookie rules never need to apply.

• When connecting to *.cofacts.org, use api.cofacts.org as API endpoint
  • Problem: need to determine API endpoint using host, and need carefully handle OAuth2 login redirect domains
• Proxy requests to /api/ to API servers instead
  • On production, this can be achieved using path matching and proxy_pass
  • On localhost dev environments, it should be achievable using dev server proxy
  • This is not only same-site but also same-origin. Can switch to simpler CORS setup (but some CORS may be still needed for chatbot LIFF), or remove CORS support completely (require chatbot LIFF to implement its own proxy as well).
  • When using proxy under each domain, we may need to take care of session cookie key collision (need to pick a different cookie name) and a problem that the login session cannot cross-domain (SSO).

Method 3: Use token & authentication header to replace cookie

No cookie, no headache! In this way, there is nothing that will "automatically" sent to server, thus no CSRF risks -- as long as the token is not intercepted :P

However, this requires clients like rumors-site to remember the token in other means (such as localStorage) if we don't want users to login after reloading the website / opening a new tab. Other things are:

• We may need to design our own token expire check (or use JWT) to replace cookie max-age mechanism.
• We may need token exchange mechanism so that the server can safely (i.e. not through redirect URLs!) send real session token (JWT) to client after the user authenticates. Usually it is achieved by server attaching a temporary code in URL after successful authentication, and the client uses the code to exchange for token and store it in client side.

[MrOrz]

Working on a branch to mitigate this, but blocked by secure detection issue:

• https://github.com/pillarjs/cookies/issues/51
• https://github.com/koajs/koa/issues/974

[MrOrz]

As secure cookie & SameSite: none being set, this issue should be resolved on staging. Visitors of localhost:3000 should be able to login staging server with no problem

If Google Chrome still complains about cross-site cookie, try clearing the cookie stored for localhost:3000 and try again. Safari login should also work as expected.

cc/ @Stimim