Is it safe to disable VerifyCsrfToken middleware on Login and Logout pages ?

Hi Vince

Ideally, after the user logs out, leave them on a page that does not have the login form.

Then when they come to login they will get a fresh form.

That aside, I have disabled csrf on login forms sometimes. There is a remote possibility of a vulnerability on login, but I don't understand it.

Logout should not need it because if the csrf token expires, the user's session has already expired and they cannot logout anyway.

Suppose your session time is 120 minutes, you can have a small javascript on the page that redirects the browser to a new page that says "you are logged out" if 120 minutes passes without the page being refreshed.

No, don't do that, especially with login/out. So now I can log in as a user from my site to yours without csrf. Not good.

The csrf is to help guarantee the request originated from your server, as only your server generates the valid token. Without that token, you've given up a lot of security and might as well remove auth.

@Snapey Thanks for that.

@Cronix Thanks for that too, however, I do not understand your point. All my views are protected by a csrf token and also the auth middleware. If I am logged out, then how can someone login after me? They have no token, and the don't know my password, so how can they be authenticated? Can you please explain in kindergarten terms? :o)

Furthermore, if I must include them with the VerifyCsrfToken middleware, then what do I do about clearing the error message, This page has expired due to inactivity, Please Refresh an d Try Again ?

Thanks

All my views are protected by a csrf token and also the auth middleware.

How? If you add a route to the VerifyCsrfToken middleware via the $except array, then the csrf token is ignored on those routes and not even being validated. Go ahead and remove the csrf token on those forms where you disabled csrf checking. They'll go right through with no csrf token error, even if they are in an auth group in the routes.

Specifically what routes did you exclude in the middleware? If it's just the routes to show the login form, that doesn't matter as get routes are ignored by csrf anyway, but if it's on the post route to login, then there's a problem as the csrf is ignored.

Goo goo ga ga. Just kidding the csrf token is generated within laravel and for that specific form post request, has nothing to do with the user.

It has to do with is that post coming from the page it is supposed to come from, and the correct site.

Here is an older article, pretty old but it explains csrf pretty well.

http://shiflett.org/articles/cross-site-request-forgeries

CSRF does not alter the security of login.

Anyone can open your login form and try to login. The csrf token does not protect against that.

The whole point of csrf is to stop someone from tricking an authenticated user into doing bad things with their authenticated account. Unauthenticated users are no threat, with or without csrf on the login form.

Anyone can open your login form and try to login. The csrf token does not protect against that.

Sure, it prevents them from being able to send the request from a 3rd party site and having it be accepted as though it came from your site. It changes it from only being able to login through a form presented on your site, to being able to login from any site. So, I disagree that it doesn't alter security of login in that regard. I wasn't talking about being able to see the form. I was talking about the actual form submission.

Thank you everyone for helping out!

Ok, following @cronix suggestion, I have removed the POST login form from the VerifyCSRFtoken middleware "except" and for some miraculous reason I am not getting the "expired" error message now.

Following @snapey suggestion, I have now got a log out page which does not include the login form.

for some miraculous reason I am not getting the "expired" error message now.

You need to let the session expire for that to happen. Default session time is 2 hours. If you sit on the page (no reloading/interacting with it) for 2 hours and 1 minute and then submit the form, it will give you the "page expired due to inactivity" error. That's a session timeout error, not a csrf error.

Ok, great. what does everybody else do for this page? Do they just leave it as is, or does everyone else produce a nice friendly page? If so, ,where is it ?

Depends on what's required for the project. Sometimes I use this package: https://github.com/GeneaLabs/laravel-caffeine

All it does is send a periodic ajax request automatically on pages that have a csrf token, which prevents the session from timing out in the first place.

Another option is to detect it in the Exception handler and redirect or something. Here's an example (untested): https://gist.github.com/jrmadsen67/bd0f9ad0ef1ed6bb594e

@vincej why the concern, just have user login again. Many Governments sites are like that.

I was on our mail in pharmacy, Express Scripts looking up a med, and had to re-login after some time went by. Usually if it's a site where any type of security should be implemented, most users will feel safer and more secure having that in place.

I am glad my Bank has that type of security.

Edit:

Was curious and looked around, found an older article that may or may not help. But wouldn't hurt to have a look:

https://laravel-tricks.com/tricks/session-timeout-for-logged-in-user

@CRONIX - Sorry for bumping this rather old thread but I am facing the exact same issue and this is the most recent and relevant thread I've found

Disabling CSRF token verification for the login route would allow the login POST request to come from any 3rd party website yes. But my understanding is that login could only be succesful if said 3rd party website tricks the user into inputting its login and password into its form. And at that point... the 3rd party website knows the login and password of the user, so with or without CSRF protection, the security breach is the same, isn't it?

@buno

CSRF does not protect against someone spoofing a login form and tricking users to enter their login details.

CSRF on login protects against one very specific condition, mentioned here;

https://stackoverflow.com/questions/6412813/do-login-forms-need-tokens-against-csrf-attacks

See "Trusted Domain Phishing Attack"

I assume you are investigating the issue of the login form expiring? You should not leave the user on a login page after they logout. Have login as a button that opens a new page when the user is ready to login.

I have collated some ideas for managing forms and the user's session on the test site at https://uxp.novate.co.uk/ The code for the site is on Github. On the test site, the session is timed out at 3 minutes and then the login form is replaced with a page that explains the session has timed out.

Thanks Snapey this example is very clear and I understand better the vulnerability it can create

I ended up here because of the "login form expiring" issue. When my users log-out, they are redirected to a page that is not a login page, but some of them complained (users will be users..) that they still experience the issue. My understanding is that it probably happens if they go themselves to the login page, leave it hanging there, go have lunch, grab a coffee, come back and then decide to log-in. That's technically the user's fault but that's not what they want to hear of course..

One solution I have in mind would be to have the login page poll every minute a "dummy" POST route. If the response is a 419 error, then refresh the login page, so as to generate a new CSRF token. Not perfect but could help in some cases, although it feels a bit "quick and dirty".. (upon reading your link, this sounds quite similar to point 3 of your Github).

Thanks

@snapey if there is no csrf on a login form does that not allow a much more convincing phish? e.g. send an email with a copy of login page on a different domain, user falls for that, fills it in, login details are captured then forwarded/reposted to the real login form and the user is logged in smoothly without any knowledge that something went wrong? As opposed to logging in and it failing first time making the user go back and question what they just did

@deansatch

Not sure I follow? If the attacker has your credentials, however obtained, they can then just login. csrf makes no difference.

Also, if I'm lured to a copycat login page, I have no way of knowing if that form has a valid csrf?

What I mean is, if the copycat page is a spoofed login page, it will fail csrf verification on your site (if it exists) when the user enters their details, basically alerting and getting their attention so they will spot the problem and change their login details.

If you don't have csrf on, the copycat page could harvest the login details then log them in seamlessly. So they might not know they've given away their credentials for a while longer...long enough for them to be exploited

@deansatch

What I mean is, if the copycat page is a spoofed login page, it will fail csrf verification on your site (if it exists) when the user enters their details, basically alerting and getting their attention so they will spot the problem and change their login details.

But the copycat is not going to be submitting the form directly. They just get the credentials and either login behind the scenes or forward you to the real login page at which point you think something went wrong, and just login as normal. Only now they have a copy of your username and password which they can use at leisure.

It’s quite hard to explain what I mean without an example but imagine these scenarios:

1. Without csrf protection I get an email asking me to login and update something. I click the link, see the familiar login page and login. It logs me in and I update stuff and log out then go about my day.

2. With csrf protection I get the email, click link, login but it fails and shows me the real login page. I go back check the email and spot the dodgy url. I quickly change my password and delete the email

In scenario 1 the hacker can create a page to spoof the login, post to a script which stores the post data, then uses curl to post it directly to the real login post endpoint and the lack of csrf protection allows it

Maybe not a huge deal but still something to think about

then uses curl to post it directly to the real login post endpoint and the lack of csrf protection allows it

except that the hacker gets a csrf token when they request the login page with curl, then posts the hidden field to the service along with the session token and your credentials. They are then logged in and can immediately change your password. Csrf makes no difference in this case.

In a recent application I made the logout go back to the login page. However if the user leaves this open and tries to login later on, they get an "expired" page which is confusing to them.

I got round this by adding this to the head of my login view:

<meta http-equiv="Refresh" content="300" />

This automatically reloads the login page every 5 minutes, and the CSRF token is re-generated if it needs to be.