Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, those requests will no longer carry cookies.
To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today.
Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies.
As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.
Before you start emitting samesite=lax, be warned that webkit/safari iOS12 has a weird implementation: if you set the cookie in a POST method and redirect to a GET (like most default oauth explicit grant login flows), the cookie will not be sent: they consider POST pages as "unsafe". See https://bugs.webkit.org/show_bug.cgi?id=188165#c12 for more details.
Edit: it looks like people have found other issues since I last looked at this bug:
> It's a serious issue affecting many common user flows, including the flow of visiting a website coming from a GMail link. If the user comes from GMail, it reaches the destination website without any cookies, thereby breaking functionalities that depend on session/login cookie and CSRF cookie. Only fix for now seems to be removing the Lax flag from cookies.
(https://bugs.webkit.org/show_bug.cgi?id=188165#c47)
At this point, it looks like the safest approach is to only emit sameSite if the browser isn't safari.
Is a SameSite=Strict cookie sent if VICTIM.COM does a redirect?
If so, it sounds like the next trick to follow would be a type of "redirect gadget" to get SameSite=Strict to be exploitable again. If so, maybe it's only the end of CSRFs without a gadget.
Eg of "redirect gadget", CSRF via VICTIM.COM/open-redirect?url=/update-password...
I read half of your comment, and thought: wow, this guy really explains things very well. Incredibly well. It's that simplicity and clearness that you only find in great teachers with very deep technical skills.
To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today.
Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies.
As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.