Начальный ~20 мин чтения

Сессии и куки: stateful аутентификация

Урок 2 из 6 в курсе Аутентификация и авторизация

Сессии и куки: stateful аутентификация

сессия — это серверное состояние пользователя; cookie — механизм передачи идентификатора сессии между браузером и сервером

Почему это важно: неправильная настройка cookie-флагов — причина XSS-кражи сессий и CSRF-атак. HttpOnly, Secure, SameSite — обязательные атрибуты

Главная идея

сервер хранит данные сессии (user_id, roles) по ключу; клиент получает только session_id в cookie и отправляет его при каждом запросе

Как это выглядит на практике

  1. Пользователь логинится: сервер проверяет пароль, создаёт сессию в БД/Redis с user_id.
  2. Сервер отвечает: Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax.
  3. Браузер автоматически отправляет cookie при каждом запросе к домену.
  4. Сервер находит сессию по session_id, достаёт user_id и определяет пользователя.
  5. Logout: сервер удаляет сессию из хранилища; cookie становится невалидным.

Что происходит под капотом

  • Session store: в памяти (только для dev), БД, Redis (рекомендуется для продакшена).
  • Session fixation attack: злоумышленник подсовывает свой session_id до логина; защита — регенерация ID после логина.
  • CSRF: браузер автоматически отправляет cookie, злоумышленник может создать форму на своём сайте. Защита: SameSite=Strict/Lax или CSRF-токен.
  • Cookie scope: Domain и Path ограничивают, куда браузер отправляет cookie.

Типичные ошибки и заблуждения

  • Ошибка: HttpOnly защищает от CSRF. HttpOnly защищает от XSS-кражи (JS не читает cookie). CSRF требует SameSite или CSRF-токен.
  • Ошибка: сессии устарели, JWT лучше. Сессии отзываемы мгновенно, JWT — нет. Для финансовых приложений сессии часто предпочтительнее.
  • Ошибка: session_id можно хранить в localStorage для удобства. LocalStorage доступен JS → XSS → кража токена. Только HttpOnly cookie.
  • Ошибка: Secure флаг шифрует cookie. Secure означает только передачу по HTTPS; содержимое не шифруется.

Ключевые выводы

  • Сессия хранится на сервере; клиент получает только непредсказуемый session_id.
  • HttpOnly: JS не читает cookie. Secure: только HTTPS. SameSite: защита от CSRF.
  • После логина регенерируй session_id (защита от session fixation).
  • Redis — стандарт для хранения сессий в продакшене.

Термины урока

Session: серверное хранилище данных пользователя с уникальным ID.
Cookie: небольшой файл на клиенте для хранения session_id.
HttpOnly: флаг, запрещающий доступ к cookie через JavaScript.
Secure: флаг, разрешающий передачу cookie только по HTTPS.
SameSite: атрибут, контролирующий отправку cookie при cross-site запросах (Strict/Lax/None).

Связь с работой backend-разработчика

Минимальный стандарт для production cookie: HttpOnly; Secure; SameSite=Lax. Session store — Redis с TTL. После успешного логина — регенерация session_id.

Мини-разбор реальной ситуации

Веб-приложение хранит session_id в cookie без HttpOnly. XSS-уязвимость в комментариях позволяет злоумышленнику вставить document.cookie и украсть сессии всех пользователей. Добавление HttpOnly полностью закрывает этот вектор атаки.

Что запомнить

  • Три обязательных флага: HttpOnly, Secure, SameSite.
  • Session store в продакшене — Redis, не память процесса.
  • Logout = удаление сессии на сервере, не только очистка cookie.

Итог

Сессии с правильно настроенными cookie — надёжный и простой механизм для веб-приложений. Три флага и Redis-хранилище закрывают большинство типичных уязвимостей.