Senior: питання на співбесіді з теми «Сесії»

Фіксація сесії (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).

Докладніше в документації: Регенерація ідентифікатора сесії

Драйвер database - за замовчуванням у нових застосунках:

• таблиця sessions з user_id, IP і user agent - можна показати користувачу активні сесії й завершити їх;
• не потрібна додаткова інфраструктура;
• кожен запит пише в базу (оновлення last_activity), на навантаженому сайті це помітне навантаження;
• очищення старих записів - через «лотерею»: 'lottery' => [2, 100] означає, що приблизно у 2 зі 100 запитів Laravel видаляє протерміновані сесії. На великій таблиці це раптово повільний запит у випадкового користувача.

Драйвер redis:

• швидкий, не навантажує основну базу;
• записи протерміновуються самим Redis через TTL - лотерея не потрібна (для драйверів на основі кешу очищення нічого не робить);
• але немає зручного запиту «всі сесії користувача» - для такої функції доведеться зберігати зв'язок окремо;
• налаштування Redis важливе: якщо в тому самому екземплярі кеш з політикою витіснення allkeys-lru, при нестачі пам'яті Redis видалятиме й сесії - користувачів почне розлогінювати. Сесії краще в окремій базі Redis чи екземплярі з noeviction.

Чого уникати:

• file на кількох серверах - кожен сервер бачить лише свої сесії;
• cookie для великих даних - ліміт розміру cookie близько 4 КБ і дані в кожному запиті;
• array - лише для тестів.

Що не зберігати в сесії:

• моделі й великі об'єкти - серіалізуються цілком, застарівають, роздувають кожен запит. Зберігайте ідентифікатори;
• дані, що мають пережити вихід (кошик зареєстрованого користувача, налаштування) - у базі;
• секрети й токени сторонніх сервісів без потреби: вміст сесії видно будь-кому з доступом до сховища (SESSION_ENCRYPT=true шифрує дані сесії);
• дані, що змінюються паралельними запитами - без блокування вони перезаписують одне одного.

Ще кілька параметрів:

• SESSION_LIFETIME - хвилини неактивності; для адмін-панелей коротше;
• SESSION_CONNECTION - окреме з'єднання з базою чи Redis для сесій;
• 'serialization' => 'json' у config/session.php замість PHP-серіалізації (за замовчуванням php) закриває клас атак через десеріалізацію, але вимагає зберігати в сесії лише прості значення.

Докладніше в документації: Налаштування сесій