Clarification on How Session Fixation Prevention Works

[shengslogar]

This is a low-level framework question prompted by the following documentation:

Regenerating the session ID is often done in order to prevent malicious users from exploiting a session fixation attack on your application.

Laravel automatically regenerates the session ID during authentication if you are using one of the Laravel application starter kits or Laravel Fortify; however, if you need to manually regenerate the session ID, you may use the regenerate method:

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

https://laravel.com/docs/10.x/session#regenerating-the-session-id

Looking at Fortify and Breeze source, we see $request->session()->regenerate() being called after a user has been successfully logged in.

This brings me to the following questions:

1. Shouldn't the session ID be regenerated before login?

My limited understanding of a session fixation attack is it relies on an attacker knowing their victim's session ID. If we just logged in a user with that known session ID, isn't regeneration after the fact (and notably not destroying the old session with regenerate(true)) no longer effective?

2. regenerate() at login seems somewhat redundant

If we inspect the standard \auth()->login($user) method, we see it calls a protected updateSession method which in turn calls $this->session->migrate(true).

If we inspect $request->session()->regenerate(), we see it's the equivalent of running $request->session->migrate(false) && $request->session->regenerateToken(). That means we're calling some form of \session()->migrate() twice on each login. Does anyone know if that's intentional?

framework/src/Illuminate/Auth/SessionGuard.php

Lines 514 to 525 in a543e61

	/**
	* Update the session with the given ID.
	*
	* @param string $id
	* @return void
	*/
	protected function updateSession($id)
	{
	$this->session->put($this->getName(), $id);
	$this->session->migrate(true);
	}

framework/src/Illuminate/Auth/SessionGuard.php

Lines 486 to 512 in a543e61

	/**
	* Log a user into the application.
	*
	* @param \Illuminate\Contracts\Auth\Authenticatable $user
	* @param bool $remember
	* @return void
	*/
	public function login(AuthenticatableContract $user, $remember = false)
	{
	$this->updateSession($user->getAuthIdentifier());
	// If the user should be permanently "remembered" by the application we will
	// queue a permanent cookie that contains the encrypted copy of the user
	// identifier. We will then decrypt this later to retrieve the users.
	if ($remember) {
	$this->ensureRememberTokenIsSet($user);
	$this->queueRecallerCookie($user);
	}
	// If we have an event dispatcher instance set we will fire an event so that
	// any listeners will hook into the authentication events and run actions
	// based on the login and logout events fired from the guard instances.
	$this->fireLoginEvent($user, $remember);
	$this->setUser($user);
	}

framework/src/Illuminate/Session/Store.php

Lines 559 to 589 in a543e61

	/**
	* Generate a new session identifier.
	*
	* @param bool $destroy
	* @return bool
	*/
	public function regenerate($destroy = false)
	{
	return tap($this->migrate($destroy), function () {
	$this->regenerateToken();
	});
	}
	/**
	* Generate a new session ID for the session.
	*
	* @param bool $destroy
	* @return bool
	*/
	public function migrate($destroy = false)
	{
	if ($destroy) {
	$this->handler->destroy($this->getId());
	}
	$this->setExists(false);
	$this->setId($this->generateSessionId());
	return true;
	}

[shengslogar]

After some debugging, I've largely answered my own question:

1. It appears in one way or another that sessions are only written at the close of a Laravel request lifecycle. Therefore, the order in which \session()->regenerate() is called doesn't matter. (You can test this by copying a Laravel session cookie into an Incognito window, writing to the session in the other window, then calling regenerate. Refreshing the Incognito window doesn't expose any newly-written session details.)
2. Assuming (1) is correct, then calling \session()->regenerate() multiple times incurs only a small performance penalty on re-randomizing a session ID. Therefore, the fact that \auth()->login() && \session()->regenerate() regenerates twice (first destroying the old session, second regenerating the recently-generated ID that wasn't used yet) is not problematic, although it would be nice to see this refactored.