RFC: Consider ditching CSRF tokens

[Bloke]

Background:

• CSRF Is dead
• CSRF is really dead
• New security headers: COOP, COEP, CORP and CORB server-config#67

In theory, we could get rid of all our token/CSRF/bouncer token validation stuff in core since we set SameSite=Lax by default and set the httponly header on the login authentication cookie. Removing the CSRF protection would be a nice thing to do as it's less work on each page request (faster), fewer bytes over the wire (less bloat, faster admin panel delivery) and we only need to validate the step names, not then do the additional check of whether the tokens match - which is less faff for plugin authors too.

I'm slightly nervous removing it, but maybe CSRF really is unnecessary. In which case, we can remove it from the 4.9 UI library and get rid of all the form_token() rubbish. Presumably if somebody created a browser that didn't respect the headers, it wouldn't last long in the marketplace! At the time of writing three minor browsers don't support SameSite so if we ripped out the CSRF protection, they'd be exposed. Not sure if that's anything to worry about given the development state of those browsers.

Thoughts?

[bloatware]

Theoretically, one txp user could throw a CSRF against another user, so SameSite wouldn't help. Should we adhere to 'trust your users' principle once again?

[Bloke]

That's a good point. The articles I cited are approaching this from a man-in-the-middle perspective - an external attack. For multi-user systems, we still have a duty of care to protect users from each other - especially since some of those users may be Publishers with keys to the castle.

In that case, CSRF still has value and we should continue to honour it. I'm fine with keeping it; just didn't want to leave it in if it served no purpose.

We do need to boost the security of the public login tokens, however.

[Bloke]

Let's park this. It's still valid to use them to protect users from each other.