Сесії й cookies: безпека PHP на прикладах

01 · ЩО ЦЕ

Рядок у cookie, який важить як пароль

HTTP не памʼятає, хто ви. Після входу сервер створює сесію: дані лежать у нього, а браузер отримує лише у cookie й надсилає його з кожним запитом. Знати id означає бути цією людиною, поки сесія жива. Тому атаки тут три: вкрасти id (XSS, перехоплення по http, логи з cookie), підкинути свій () або змусити браузер надіслати cookie з чужого сайту (CSRF).

СЛОВНИКId сесії. Випадковий рядок, за яким сервер знаходить дані сесії. У Laravel це 40 символів Str::random, у PHP за замовчуванням 32. Має бути непередбачуваним і жити лише в cookie, не в адресі.

СЛОВНИКФіксація сесії. Атака, коли жертва входить із id, який заздалегідь знає атакувальник. Якщо після входу id не змінився, атакувальник надсилає той самий id і стає жертвою.

Фіксація працює так: атакувальник отримує від сайту справжній id і підкидає його жертві через cookie з піддомену чи посилання на старий застосунок, що приймає id з адреси. Жертва входить, сервер пише user_id у ту саму сесію, і id атакувальника стає залогіненим. Захист один: після входу видати новий id. У PHP це session_regenerate_id(true), у Laravel $request->session()->regenerate(). Auth::login і Auth::attempt уже роблять regenerate(true) всередині SessionGuard, тож виклик у контролері страхує вхід, який іде повз guard, і заодно оновлює CSRF-токен.

Вихід має знищити сесію на сервері: Auth::logout() прибирає користувача й змінює remember_token, якщо він був, $request->session()->invalidate() стирає дані й видає новий id, regenerateToken() міняє CSRF-токен. Сама cookie нічого не вирішує: її можна зберегти й надіслати пізніше, тому значення має лише те, що сервер зробив із сесією.

Три прапорці cookie закривають три шляхи. не дає браузеру надіслати cookie по http, де її видно в мережі. ховає її від JavaScript, тож XSS не прочитає document.cookie, хоча діяти від імені людини на сторінці зможе. вирішує, чи йде cookie із запитом, який почався на іншому сайті: Lax пропускає звичайний перехід за посиланням і не пускає POST з чужої форми, fetch чи iframe, Strict не пускає навіть перехід, None пускає всюди й вимагає Secure. У Laravel це secure, http_only і same_site у config/session.php.

СЛОВНИКSecure. Прапорець cookie: браузер надсилає її лише по https. Без нього одна адреса http:// у мережі кавʼярні показує id сесії кожному, хто слухає.

СЛОВНИКHttpOnly. Прапорець cookie: JavaScript її не бачить, document.cookie її не містить. Захищає id від крадіжки через XSS, але не від дій скрипта в тій самій вкладці.

СЛОВНИКSameSite. Атрибут cookie зі значенням Strict, Lax або None. Каже браузеру, чи додавати cookie до запитів, що почалися на іншому сайті. Lax стоїть у Laravel за замовчуванням, і так само Chrome трактує cookie без атрибута.

lifetime у Laravel рахує хвилини без активності: кожен запит продовжує сесію, а абсолютної межі фреймворк не ставить. Драйвер file тримає сесії на диску одного сервера, database дає таблицю sessions з user_id і last_activity, тож можна показати активні сесії й закрити будь-яку, redis швидкий і сам видаляє прострочені ключі. Драйвер cookie кладе всі дані в зашифровану cookie, і закрити таку сесію на сервері неможливо. живе окремо: cookie remember_web_… на 400 днів, яку Laravel звіряє з remember_token у таблиці users. Auth::logoutOtherDevices($password) і middleware AuthenticateSession закривають решту сесій, коли змінюється хеш пароля.

СЛОВНИКRemember me. Довга cookie, з якою Laravel відновлює вхід після закінчення сесії. Містить id користувача, remember_token і хеш пароля, зашифровані APP_KEY. Зміна токена в базі робить усі такі cookie недійсними.

02 · ЯК ДУМАЄ АТАКУВАЛЬНИК

Три кроки фіксації сесії

ДІАГРАМА · УСЯ СХЕМА

Уся схема. Натисніть → або виберіть крок нижче, щоб пройти по ній частинами.

Клієнт Ключовий учасник Інфраструктура

Атакувальник створює id сесії a1b2….
id сесії a1b2… використовує Жертва (підкинув).
Дані йдуть від Жертва до Вхід на сайт.
Вхід на сайт використовує Сесії (той самий id).
Атакувальник надсилає подію запити з a1b2…, її отримує Сесії.

03 · ВРАЗЛИВИЙ І ЗАХИЩЕНИЙ КОД

Новий id після входу

PHP 8.5

1<?php

3session_start();

4$user = ['id' => 42, 'password' => password_hash('secret', PASSWORD_DEFAULT)];

5$before = session_id();

7// Було: вхід пише user_id у ту саму сесію, з якою людина прийшла.

8if (password_verify($_POST['password'] ?? 'secret', $user['password'])) {

9 $_SESSION['user_id'] = $user['id'];

10}

12echo $before === session_id() ? "id той самий, що до входу\n" : "id новий\n";

14// Було: вихід прибирає одне поле, а id сесії й решта даних живі.

15unset($_SESSION['user_id']);

1<?php

3// Сховище сесій: як storage/framework/sessions чи таблиця sessions.

4$sessions = [];

6function startSession(array &$sessions): string

8 $id = bin2hex(random_bytes(20));

9 $sessions[$id] = [];

11 return $id;

12}

141// Як regenerate(true) у Laravel: дані під новим id, старий знищено.

15function regenerate(array &$sessions, string $id): string

16{

17 $new = bin2hex(random_bytes(20));

18 $sessions[$new] = $sessions[$id];

19 unset($sessions[$id]);

21 return $new;

22}

24function login(array &$sessions, string $id, int $userId, bool $regenerate): string

25{

262 if ($regenerate) {

27 $id = regenerate($sessions, $id);

28 }

30 $sessions[$id]['user_id'] = $userId;

32 return $id;

33}

353foreach ([false, true] as $regenerate) {

36 $planted = startSession($sessions); // id, який атакувальник отримав від сайту

37 $victim = login($sessions, $planted, 42, $regenerate); // жертва входить із цим id

39 $stolen = $sessions[$planted]['user_id'] ?? null;

40 echo $regenerate ? 'З regenerate: ' : 'Без regenerate: ';

41 echo $stolen === null ? "id атакувальника нічого не дає\n" : "id атакувальника тепер user {$stolen}\n";

42}

444// Вихід, як invalidate(): дані стерто, старого id на сервері більше немає.

45unset($sessions[$victim]);

46echo 'Після виходу: ', isset($sessions[$victim]) ? 'сесія жива' : 'сесії немає', "\n";

Перший запуск завантажить рушій PHP 8.5, приблизно 3,8 МБ Відкрити в пісочниці ↗

ВИВІД

Завантажуємо рушій PHP 8.5

Лише перший раз. Далі код запускається миттєво, рушій лишається в кеші браузера.

$ php main.php ▍

1 рядки 14–22
Те, що робить regenerate(true): дані переїжджають під новий випадковий id, а старий запис знищено. У чистому PHP це session_regenerate_id(true).
2 рядки 26–28
Новий id видається до того, як у сесії зʼявиться user_id. Laravel робить це в SessionGuard при кожному Auth::login.
3 рядки 35–41
Атакувальник тримає id, з яким жертва прийшла. Без regenerate цей id після входу стає залогіненим, з regenerate він веде в нікуди.
4 рядки 44–46
Вихід знищує сесію на сервері. Стара cookie з цим id більше нічого не відкриває, навіть якщо її хтось зберіг.
Наведіть на пояснення, щоб підсвітити рядки.Торкніться пояснення, щоб підсвітити рядки.

04 · ПАСТКИ ФРЕЙМВОРКУ

Laravel керує сесією сам, крім цих місць

LARAVEL · ВХІД ПОВЗ GUARD

session(['user_id' => $user->id]);

Чому це дірка: Власний «вхід» записом у сесію обходить SessionGuard, і id не змінюється. Входьте через Auth::login чи Auth::attempt, а після них викликайте $request->session()->regenerate().

LARAVEL · ВИХІД

Auth::logout(); return redirect('/');

Чому це дірка: logout прибирає користувача, але дані сесії й id лишаються. Додайте $request->session()->invalidate() і regenerateToken(), інакше старий CSRF-токен і решта даних живуть далі.

LARAVEL · SECURE

'secure' => env('SESSION_SECURE_COOKIE')

Чому це дірка: Порожнє значення означає «як запит»: по https Symfony ставить Secure сам. За проксі застосунок має знати про https через trustProxies, інакше Secure не буде. У продакшені надійніше SESSION_SECURE_COOKIE=true.

LARAVEL · SAMESITE NONE

'same_site' => 'none'

Чому це дірка: Cookie піде з будь-якого сайту, і браузер прийме її лише разом із Secure. Захист від CSRF тоді тримає лише токен. Беріть lax, а none лишайте для віджетів в iframe на чужих доменах.

LARAVEL · DOMAIN

SESSION_DOMAIN=.example.com

Чому це дірка: Cookie отримують усі піддомени, тож вразливий блог чи стенд на піддомені її прочитає. Без потреби лишайте null, тоді cookie належить лише одному хосту.

LARAVEL · ДРАЙВЕР COOKIE

SESSION_DRIVER=cookie

Чому це дірка: Уся сесія лежить у зашифрованій cookie. Закрити її з сервера неможливо, вихід з інших пристроїв і список активних сесій не працюють. Для акаунтів беріть database або redis.

LARAVEL · REMEMBER ME

Auth::login($user, remember: true);

Чому це дірка: Cookie remember_web_… живе 400 днів і переживає закінчення сесії. Зміна пароля має змінити remember_token, а з AuthenticateSession у групі web старі cookie перестають діяти самі.

PHP · SID В АДРЕСІ

ini_set('session.use_trans_sid', '1');

Чому це дірка: id сесії потрапляє в посилання, Referer і логи, а фіксація стає тривіальною. У PHP 8.4 це застаріло. Лишайте use_only_cookies=1 і вмикайте use_strict_mode=1, щоб PHP не приймав id, якого сам не видавав.

SYMFONY · SECURITY

framework: { session: { cookie_secure: auto, cookie_samesite: lax } }

Чому це дірка: Symfony після входу мігрує сесію сам: session_fixation_strategy у security.yaml типово migrate, не ставте none. cookie_secure: auto за проксі працює лише з правильними trusted_proxies.

05 · ЗНАЙДИ ПРОБЛЕМУ