0

We recently got our Laravel 5.6 application penetration tested and one of the issues which were flagged was the expiration not being set correctly on Logout. The AuthenticatesUsers trait calls the invalidate method on the session which basically flushes the session data and regenerates the ID but doesn't set expiration to it.

According to the report, if an attacker can obtain a valid session token, they will be able to hijack the affected user’s account. The user logging off will not invalidate the attacker’s session.

Any pointers here would be of great help.

Thanks

/**
 * Log the user out of the application.
 *
 * @param  \Illuminate\Http\Request  $request
 * @return \Illuminate\Http\Response
 */
public function logout(Request $request)
{
    $this->guard()->logout();

    $request->session()->invalidate();

    return redirect('/');
}
aliasunknown
  • 49
  • 5

1 Answers1

1

Laravel 5.6 added an Auth::logoutOtherDevices() method for this purpose:

https://laravel.com/docs/5.7/authentication#invalidating-sessions-on-other-devices https://laracasts.com/series/whats-new-in-laravel-5-6/episodes/7 https://github.com/laravel/framework/issues/16311

Travis Britz
  • 5,094
  • 2
  • 20
  • 35
  • But this is happening on the same device, so not sure doing this would help. The logout functionality is fine and itself, the problem is with the expiry time not being set on logout. – aliasunknown Feb 11 '19 at 22:48
  • Isn't the core problem that an attacker gaining a session won't have their session invalidated? `Auth::logoutOtherDevices()` will invalidate *all other sessions* besides the current one, which solves *that* problem. Using the logout button to expire all other sessions is not typical behavior, e.g. if you log out of gmail on the library computer you don't expect your laptop to also get logged out. – Travis Britz Feb 11 '19 at 22:59
  • Correct me if I am wrong here, but if an attacker has the same session token as the actual user and even though the actual user has logged out, wouldn't that mean the session token could still be reused as it doesn't have an expiry date set? – aliasunknown Feb 12 '19 at 00:27
  • Unless I'm horribly misinterpreting the code I'm reading, I'm pretty sure logging out of the *same* session the attacker stole would invalidate that session, like if they man-in-the-middled your cookies. Maybe it's the wording of your pentester's report that's confusing, because if an attacker logs in on another browser then they have their own, separate session from the one you've just logged out of. That's where `Auth::logoutOtherDevices()` would invalidate those sessions - one user can have multiple active sessions. – Travis Britz Feb 12 '19 at 00:47
  • I actually thought the same as you mentioned about invalidating the same session for the attacker. But the pentester's were able to replicate a request with a logged out user's session. Not sure how they ended up doing this (or which tools they were using). The only pointers I got from those guys was to refer to https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Expiration. – aliasunknown Feb 12 '19 at 01:03
  • I don't know what to tell you, I just went digging through the framework and as best I can tell it deletes the session token when you log out. You might want to ask them for some clarification. – Travis Britz Feb 12 '19 at 01:15