October: CSRF validation is failing if request is not made in a form

[filipac]

• OctoberCMS Build: ###
• PHP Version: 7.3

Description:

In this commit: https://github.com/octobercms/october/commit/d31006ae1a1f5a709e9a100d0096a5633ab820b5 the csrf validation was improved/changed, but it introduced a new bug: when requests are made without a form (like data-request on a modal), the csrf error is shown. It breaks a lot of calls for users than use the ajax framework without a form.

We talked on Slack about this @LukeTowers. I would suggest reverting the error until we can fix this to avoid breaking changes.

[LukeTowers]

@bennothommo any ideas how to best deal with this? We could add support for a global CSRF token in the head that the framework.js file would fall back on but then we'd still need people to update their themes to include it.

[bennothommo]

@LukeTowers We could potentially use localStorage or sessionStorage to provide a fully JS-provided implementation of CSRF tokens and not require any theme changes, as localStorage and sessionStorage are only accessible by the exact domain that the data was created in. However, this sort of setup is still vulnerable to XSS if people allow unknown JavaScript to run on their site.

[LukeTowers]

@bennothommo if people allow unknown JS to run on their site it's no longer XSS is it? 😄

[bennothommo]

@LukeTowers that's fair ;). What do you reckon, worth looking at a localStorage version then?

[LukeTowers]

@bennothommo as long as it works in IE11 that sounds like a good idea to me. We'll have to make sure that existing token setups take precedence though, and we might need to look at being able to update that token based on a response from the server.

[bennothommo]

@LukeTowers I've had a look at our options. Basically, the only reliable way of passing the token from the response to the JavaScript that doesn't require any modification of themes and bypasses view caching is through a cookie.

It does require said cookie to be set as "non-HTTP only" (so the JS can read it), and also requires the cookie to be unencrypted, but given CSRF tokens are generally supposed to be nonces, this is not really an issue.

What sort of use case are you looking at that would require a new token to be passed back from the server? Multiple AJAX requests?

[ghost]

@LukeTowers @bennothommo

I would like to see this built into October, see plugin: https://octobercms.com/plugin/vdlp-csrf

That plugin makes a global CSRF.

It would be great if October automatically added this meta-tag:

<meta name="csrf-token" content="{{ csrf_token() }}">

[bennothommo]

@ayumihamasaki2019 we're trying to investigate ways in which CSRF checks can be applied transparently, ie. without a need to add a meta tag to the theme or manually adding the token to any requests.

(Apologies to the VDLP team, I know you only just released that plugin).

[ghost]

@bennothommo

A lot of security researches say Same-Site Cookies replace the older Anti-CSRF tokens. Currently Google is doing a full blown trial on this, here's the link: https://www.chromium.org/updates/same-site

Also Google has just update Chrome to test your cookies:

Cookies highlighted in yellow don't have strict Same-Site settings and are not stored by the browser by the new method currently being beta tested. Same-Site Cookies with Strict are stored. This helps to generate the Cookie hash key every time in a non-secure enviroment and a single time in a secure enviroment. Thus replacing the need to generate a unqie CSRF token.

This is how the modern browsers seem to be getting rid of CSRF attacks. But as people still use older browsers I use a combination of Same-Site and CSRF tokens.

• Hope that info helps you out in some kind of way.

Will follow this thread as interested to see what kind of Global solution you come up with.

[bennothommo]

@ayumihamasaki2019 I've already submitted a PR with a proposed alternative solution here: https://github.com/octobercms/october/pull/4701. I'd be happy to hear your thoughts on that.

[LukeTowers]

Fixed by #4720.