Skip to main content

Insecure functionality - Session management

Need

Secure session management

Context

  • Usage of PHP 7.0+ for server-side scripting and web development
  • Usage of Laravel framework for PHP web development
  • Usage of Illuminate/Support for providing foundational support classes and utilities in Laravel framework
  • Usage of Illuminate/Http for HTTP request handling in Laravel
  • Usage of illuminate/session for managing session data in a Laravel application
  • Usage of Illuminate/Auth for authentication and authorization in Laravel

Description

Non compliant code

<?php
// This is an example of a basic session management code in Laravel
// The session is started when the user logs in
public function login(Request $request) {
$credentials = $request->only('email', 'password');
if (Auth::attempt($credentials)) {
$request->session()->regenerate();
return redirect()->intended('dashboard');
}
return back()->withErrors([
'email' => 'The provided credentials do not match our records.',
]);
}

// The session is regenerated when the user logs out
public function logout(Request $request) {
Auth::logout();
$request->session()->invalidate();
$request->session()->regenerateToken();
return redirect('/');
}
?>

The above code is an example of session management in a Laravel application. When a user logs in, the login() function is called, which checks the user's credentials and, if they are valid, starts a new session with $request->session()->regenerate().

When the user logs out, the logout() function is called. This function logs the user out, invalidates the session with $request->session()->invalidate(), and regenerates the session token with $request->session()->regenerateToken().

The vulnerability lies in the fact that the session token is only regenerated, not completely invalidated and recreated. This means that if an attacker gets hold of an expired session token, they can modify the expiration time and continue to use the token to make requests to the application. This is a serious security issue as it allows unauthorized access to the application.

Steps

  • Implement a server-side session management where the server has full control over the session tokens.
  • Ensure that the session tokens cannot be manipulated by the client-side.
  • Set a strict expiration time for session tokens on the server-side and do not allow this to be modified.
  • When a session token expires, invalidate it on the server-side and do not allow it to be used again.
  • Use secure and httpOnly cookies to store session tokens to prevent cross-site scripting (XSS) attacks.
  • Implement a mechanism to detect and handle session fixation attacks, such as regenerating the session token after a successful login.

Compliant code

<?php
use Illuminate\\Support\\Facades\\Session;

public function login(Request $request) {
$credentials = $request->only('email', 'password');
if (Auth::attempt($credentials)) {
// Regenerate session ID upon successful login to prevent session fixation
$request->session()->regenerate();
// Set session token in a secure and httpOnly cookie
setcookie('session_token', Session::getId(), [
'secure' => true,
'httponly' => true,
'samesite' => 'Strict',
]);
return redirect()->intended('dashboard');
}
return back()->withErrors([
'email' => 'The provided credentials do not match our records.',
]);
}

public function logout(Request $request) {
Auth::logout();
// Invalidate the session on the server-side
$request->session()->invalidate();
// Regenerate session token
$request->session()->regenerateToken();
// Clear the session token cookie
setcookie('session_token', '', time() - 3600);
return redirect('/');
}
?>

The updated code implements a secure session management mechanism in a Laravel application.

In the login function, upon successful authentication, the session ID is regenerated using $request->session()->regenerate(). This is a countermeasure against session fixation attacks. A session token is then set in a secure and httpOnly cookie. The 'secure' flag ensures that the cookie is only sent over HTTPS, preventing the session token from being intercepted during transmission. The 'httpOnly' flag prevents the cookie from being accessed through client-side scripts, mitigating the risk of cross-site scripting (XSS) attacks. The 'samesite' attribute is set to 'Strict' to prevent the cookie from being sent in cross-site requests, providing some protection against cross-site request forgery (CSRF) attacks.

In the logout function, the session is invalidated on the server-side using $request->session()->invalidate(), ensuring that the session token cannot be used again. The session token is then regenerated using $request->session()->regenerateToken(). Finally, the session token cookie is cleared by setting its value to an empty string and its expiration time to one hour in the past.

This approach ensures that the server has full control over the session tokens, and that they cannot be manipulated by the client-side. It also sets a strict expiration time for session tokens on the server-side and does not allow this to be modified.

References