L5 - Properly handle TokenMismatchException when logging in

Increasing the duration of the session in config/sessions.php ? (default : 120 min)

@pmall thanks for the suggestion, but unfortunately their use case can mean that a workstation sits with the login window open for a long period of time. I'm really hoping to avoid them seeing "a screen that looks like Greek," as they often phrase it.

Put a js to reload the page every hour :)

With L5.1 you will be able to easily exclude urls from csrf verifications. http://laravel.com/docs/master/routing#csrf-protection

@opheliadesign Thanks for the heads up on this issue, I experienced it today but didn't manage to work out why it happened. As @pmall says I'm sure there would be a JS workaround but, like you, I feel there really should be a more graceful way to handle this issue.

Guess the Javascript reload is the best option.. just feels wrong to me.

I'm already ignoring several routes for CSRF in L5 because otherwise a lot of features will not function, such as external webhooks.

@opheliadesign @robgeorgeuk found this on stackoverflow.

Create a custom exception render in the App\Exceptions\Handler class (in the /app/Exceptions/Handler.php file).

 /**
 * Render an exception into an HTTP response.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Exception  $e
 * @return \Illuminate\Http\Response
 */
public function render($request, Exception $e)
{
    if ($e instanceof ModelNotFoundException) {
        $e = new NotFoundHttpException($e->getMessage(), $e);
    }

    if ($e instanceof TokenMismatchException) {

        return redirect(route('login'))->with('message', 'You page session expired. Please try again');
    }

    return parent::render($request, $e);
}

Try this

https://github.com/GeneaLabs/laravel-caffeine

From: https://laracasts.com/discuss/channels/laravel/csrf-token-mismatch-error-on-session-timeout-form/?page=1

@jimmck that's what I am now using on all projects, love it. @subbe thanks for the resources. :)

does laravel-caffeine work well with SPA app or ajax? react for example.

I am also using laravel-caffeine, which is great if the computer sits open and connected to the internet. The problem is when you are using on a laptop or something and the laptop gets shut or disconnected from the internet and then you open the laptop expecting to be able to login and cannot without getting a mismatch error. Would really like a better solution that just removing csrf protection completely or forcing them to login twice with an error saying your session expired. To an end user this isn't neat and for security its not ideal to remove csrf completely.

I was able to solve this pretty simply essentially using what OP had posted at the beginning:

In: app\Exceptions\Handler.php

Be sure to add TokenMismatchException to the top:

use Illuminate\Session\TokenMismatchException;

Then in your render method:

if ($e instanceof TokenMismatchException){
    return redirect()->back()->withError("The login form has expired, please try again. In the future, reload the login page if it has been open for several hours.");
}

Obviously you would need to change "withError" to however you are currently passing error messages to the user, but this worked fine for my case

@subbe's suggestion was close but didn't quite nail it for me. The following tweak did:

if ($e instanceof \Illuminate\Session\TokenMismatchException) {
    return redirect('/auth/login')->with('message', 'You session expired. Please try again.');
} 

@mrjonleek just exclude login from csrf protection - it is of no use on that form (it is not protecting anything)

@Snapey can you please explain why isn't it protecting anything?

@novakkornel

the point about csrf is to stop another page in your browser from posting to your account.

So imagine if you had a page on your site that took input and changed the contents of the database, amended an account rights, placed an order or whatever, then that malicious form could cause some damage.

But, with your login form, what damage can be done if another application tries to write to your login page? As the login page is typically public access then it's no different to just entering gibberish directly to the login form

so, the short answer is; as the login form is public, csrf provides no additional protection.

@Snapey Thanks, I was thinking if one tried to break into my page with brute force it would be easier without csrf as he could post credentials to my login route from a different server, check for the response and see if passed.

@novakkornel the standard authentication has rate limiting to protect against brute force attacks

@Snapey Great point! CSRF token (as it's name says) is meant to protect authenticated users from making unauthorized requests towards my application. So there really is nothing to protect if user is not logged in yet.

Putting token validation on each and every form is plain wrong.

In case of public forms (not just login), this exception is just getting in the way of the innocent customers.

Public stuff needs to feel nice and smooth to new users. Do I as a developer really want to make my potential customers go through 'Your session has expired' scenario before they haven't even joined? No way! If I've created a session for a reason (e.g. to anonymously track their activity) - it is my problem, not theirs.

I have recently had to deal with tokens on an anonymous search form which does nothing but create doubt in our competence (as a dev team).

Regarding brute force attacks - anyone seriously trying to such attack will simply write the code to load the correct token right before attempting an attack.

Session expiration in the first place is measure taken to free the server resources when users are idle. It might be somewhat helpful to protect users who forget to lock their device while they are away.

@mrjonleek and @subbe this really helped me a lot Thanks!

CSRF on a login form is actually a vital part in protecting your visitors from malicious activity and possibly user information extraction. When you remove the CSRF protection on the login form, an attacker can create a cross site login request for it's victim with valid credentials - credentials the attacker knows since it's their account. When the victim is - within session time limit - navigating to your site, he is immediately logged in. due to the previously executed cross site login request. That is to say: in the attackers account. When the victim then wants to sign up on your website, he'll be ending up on the account page (since the create account/login page is most likely nowhere to be found for already logged in users).

It's harsh to say, but the average website visitor is either ignorant or plain dumb (have seen this to often), thus he probably won't notice he's logged in into an account which is not his. After going to the account page to update it's profile information (or thinking he's going to sign up), the attacker can then log in into his own account, which the victim just updated and by that, has access to account information of the victim.

This might be low prio or even a non-issue in other/your cases. In our case a high level of account information protection is required so the CSRF protection on the login form is not something to get rid of.

*Just wanted to put this attack vector here to give everyone a complete view on the importance of CSRF protection on the login form.