Фіксація сесії (session fixation): зловмисник отримує ідентифікатор сесії на сайті як гість і якимось чином змушує жертву користуватися саме ним (через вразливий піддомен, що встановлює cookie, через XSS чи спільний комп'ютер). Жертва входить - сесія з відомим зловмиснику ідентифікатором тепер автентифікована, і він заходить в акаунт.
Захист - новий ідентифікатор при зміні рівня привілеїв:
if (Auth::attempt($credentials, $request->boolean('remember'))) {
$request->session()->regenerate();
return redirect()->intended('/dashboard');
}
regenerate() видає новий ідентифікатор, зберігаючи дані сесії. Старий ідентифікатор більше нічого не дає. Starter kits і Fortify роблять це самі, але у власному контролері входу про це легко забути.
Вихід - три кроки:
Auth::logout();
$request->session()->invalidate(); // видалити дані й видати новий ідентифікатор
$request->session()->regenerateToken(); // новий CSRF-токен
return redirect('/');
Auth::logout()лише прибирає користувача з гарду - решта даних сесії (кошик, флеш, дані іншого гарду) лишається;invalidate()очищує сесію і знищує запис у сховищі, тож старий ідентифікатор не можна використати;regenerateToken()- щоб CSRF-токен з попередньої сесії не працював.
Інші моменти, де варто регенерувати:
- підвищення привілеїв (вхід в адмін-режим, імперсонація й вихід з неї);
- зміна пароля - разом з
Auth::logoutOtherDevices($password), щоб завершити сесії на інших пристроях.
Що ще захищає сесію:
- cookie з
HttpOnly,SecureіSameSite=Lax- налаштування вconfig/session.php; SESSION_DOMAINбез зайвої крапки: cookie для.example.comбачать усі піддомени, і вразливий піддомен стає точкою атаки;- обмежений
lifetimeіexpire_on_closeдля чутливих застосунків; - для API з токенами (Sanctum) аналог - відкликання токенів при виході й зміні пароля.
Перевірка в тесті: ідентифікатор сесії після входу має відрізнятися від початкового - expect(session()->getId())->not->toBe($before).