CSRF Support for SameSite

[rwinch]

Summary

An alternative to using the synchronizer token pattern is to use the approach described in https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-5.2

Setting the "SameSite" attribute in "strict" mode provides robust
defense in depth against CSRF attacks, but has the potential to
confuse users unless sites' developers carefully ensure that their
session management systems deal reasonably well with top-level
navigations.

Consider the scenario in which a user reads their email at MegaCorp
Inc's webmail provider "https://example.com/". They might expect
that clicking on an emailed link to "https://projects.com/secret/
project" would show them the secret project that they're authorized
to see, but if "projects.com" has marked their session cookies as
"SameSite", then this cross-site navigation won't send them along
with the request. "projects.com" will render a 404 error to avoid
leaking secret information, and the user will be quite confused.

Developers can avoid this confusion by adopting a session management
system that relies on not one, but two cookies: one conceptualy
granting "read" access, another granting "write" access. The latter
could be marked as "SameSite", and its absence would provide a
reauthentication step before executing any non-idempotent action.
The former could drop the "SameSite" attribute entirely, or choose
the "Lax" version of enforcement, in order to allow users access to
data via top-level navigation.

[eleftherias]

@rwinch is this similar to gh-4341, or is it about replacing the synchronizer token pattern we are currently using?

[rwinch]

It is different. We want to persist the expected CSRF token in a cookie marked with SameSite strict. If the cookie is present in supported browser, then we know that the request originated from the same site.

[phalt]

Hey folks. This is marked for 5.3.0 milestone, but I don't see it in the release notes.
We have started to encounter an issue with SameSite and we want to be prepared for the wider release in future browsers - is this being implemented soon?

[samuelstein]

An easy way around this problem is to use org.springframework.http.ResponseCookie class. The class has a nice builder with samesite property.
Then you can add the cookie to the response header:
response.addHeader(HttpHeaders.SET_COOKIE, ResponseCookie.from(name, value).build().toString());

[rwinch]

@phalt It's probably not obvious, but the the .x milestones are buckets of items that we would like to get into a release, but haven't planned capacity for it. That means this has not been concretely planned for a release. I have also updated the milestone description to be more informative.

[samuelstein]

thanks @rwinch. i can understand but google chrome is pushing hard to enforce this.

[rwinch]

Would someone be interested in submitting a pull request using ResponseCookie?

[codecracker2014]

I would like to take this one. I think this should be fixed for all cookies, also value should be configurable.

[rwinch]

Thank you @codecracker2014 This issue is yours. I'd suggest creating separate tickets/PRs for any other places that need updated.

[tokuhirom]

@codecracker2014 any updates on this?