CSRF Token issue (419) after 10.23.1 update & latest Edge & Chrome update

[JF-626164]

Laravel Version

10.23.1

PHP Version

8.1.12

Database Driver & Version

No response

Description

On Friday, 9/15/23, Laravel version 10.23.1 was released. Edge & Chrome also had updates that day, versions 117.0.2045.31 and 117.0.5938.89 respectively.

Before that Friday, there were no issues with my Laravel project. I received an notice from a user that day that they were encountering a 419 error message when they tried to login. Today the issue remains and is across all environments. Local dev, Server Dev and Production.

Whenever a user tries to log in; when they lad on the login page, when using either Chrome or Edge, they are immediately prompted with an alert notifying them that the page has expired and to please refresh. I've modified code to get me straight to the login, and when I try to the POST route takes me to a 419 | Page Expired error page.

On the login blade, I'm using a form post to send the users login details to the controller. In it is "@csrf" tag as mentioned in the laravel documentation. So it's getting and using the correct token. But when the login button is pressed, all the way in the vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken, in the tokensMatch function: The $token variable and the $request->session()->token() are not the same.

Important Notes:

1. no code changes have been made to the login process in months. The only changes recently were the Laravel, Chrome & Edge updates.
2. Loging in with Firefox works perfectly.
3. My clients are forced to use Edge due to government restrictions.
4. I did downgrade laravel/framework in my dev environment to version 10.15, this error was present there.

Any and all advice is welcome.

Steps To Reproduce

1. Update Chrome & Edge to the latest versions.
2. Using composer, update Laravel to the latest
3. Using Edge, go to application login, error should appear on page load.

[valorin]

Do you mean that they see the CSRF error when first going to the form, or after submitting?
If it's loading on the first access, it suggests the page is being loaded from cache or via a POST request, rather than a GET request, since CSRF shouldn't be checked on a CSRF request.

Does it happen when you manually type the direct login URL into the browser?

[crynobone]

I did downgrade laravel/framework in my dev environment to version 10.15, this error was present there.

So downgrading doesn't make any difference?

[JF-626164]

I did downgrade laravel/framework in my dev environment to version 10.15, this error was present there.

So downgrading doesn't make any difference?

Correct, downgrading Laravel made no difference.

[JF-626164]

Do you mean that they see the CSRF error when first going to the form, or after submitting? If it's loading on the first access, it suggests the page is being loaded from cache or via a POST request, rather than a GET request, since CSRF shouldn't be checked on a CSRF request.

Does it happen when you manually type the direct login URL into the browser?

After submitting the form.
I've tried clearing the browser cache and viewing the page with the in-private browser, issue was still there.

[JF-626164]

The thing about this issue that truly confuses me is that it only appears in the latest versions of Chrome & Edge. Users with versions 116 or older of Chrome or Edge work just fine. And the latest Firefox works perfectly.

Unfortunately, due to the nature of my clients I cannot have them change browsers from Edge to Firefox.

[JF-626164]

In the config/session.php, I am setting 'same_site' to 'strict'.

Also;

When I follow the route, in Edge, from submitting the form all the way to the tokensMatch function in the vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken, and dump out the $token and dd out the $request->session()->token(), they are not the same.

And yet when I do the same in Firefox, the tokens are the same.

This is driving me crazy.

[valorin]

Try using Lax instead of Strict for the same site cookies. It's possible it's blocking the CSRF token being set.

[JF-626164]

No noticeable difference. same_site is set to lax.
Chrome & Edge: 419
Firefox: success

[JF-626164]

I need to clarify my previous post about the same_site session variable, until last night I was using lax. I've set it to strict this morning in the hopes that will fix it but did not.

[morloderex]

@JF-626164 If you open up the devtools in the affected chrome browser do you see any blocked cookies within the console or the networking tab?

[JF-626164]

@JF-626164 If you open up the devtools in the affected chrome browser do you see any blocked cookies within the console or the networking tab?

I do not see any blocked cookies. The only error I see is when the post request is made, it 419s. The laravel_session csrf token is present in the request.

[morloderex]

@JF-626164 Which session store do you use?

[JF-626164]

Redis

[JF-626164]

Could having domain => null in the config/session be causing the problem?

[JF-626164]

I tried setting the domain to localhost, and when I tested on my localhost it still 419'd on me.

[JF-626164]

I've changed the session driver to be file so I can watch the csrf tokens get created.

With Chrome, Edge, and Firefox, when I land on the login page a single csrf token is created. I have a message that the users must click "I Accept" to before they can login.
When that button is clicked, in Chrome & Edge, a new token is created, while the login page still has the first token. However with Firefox, no new token is created.

Attempting to login with Chrome & Edge fails, csrf token mismatch. While Firefox succeeds.

Looking in the browser developer tools:
With both Chrome & Firefox, when I land on the page, I have two tokens: laravel_session & xsrf-token.

When I click accept in Chrome, a new token gets created in the storage. Not so with Firefox.

When I login with Firefox, thats when I get the laravel_token.

I believe Firefox is correctly getting the token from the user session, while Edge & Chrome are failing.

[JF-626164]

So far the only fix I've found for this is to add my login routes to the csrf exceptions list.

[JF-626164]

True

[JF-626164]

I've figured it out.
In my auth code when rendering the auth.login view. I was loading the view with the header clear-site-data: "cache", "cookies", storage", "executionContexts". When I removed the cookies from the list, everything functioned perfectly fine.

This code has been in my project since April to make sure users didn't skip the login process. Its weird to me that it didn't cause an error like this back then. When Chrome & Edge updated last week, something related to that header must've been updated to work.

Thank all of yall for trying to assist me with this.