Сессии, cookies, авторизация и аутентификация

Сессии, cookies, авторизация и аутентификация

Введение

Аутентификация и авторизация — одна из самых важных областей тестирования. Ошибки здесь могут привести к утечке данных, несанкционированному доступу или полному взлому системы. В этом уроке разберём ключевые понятия и то, как правильно тестировать механизмы доступа.

Аутентификация vs Авторизация

Это два разных понятия, которые часто путают:

Сценарий: пользователь вводит логин/пароль (аутентификация) → система определяет его роль → решает, что ему можно делать (авторизация).

Session-based аутентификация

Классический подход с хранением состояния на сервере:

1. POST /login → сервер создаёт сессию, возвращает Set-Cookie: sessionId=abc123
2. Браузер автоматически отправляет cookie в каждом следующем запросе
3. GET /profile → Cookie: sessionId=abc123 → сервер ищет сессию в хранилище
4. POST /logout → сервер удаляет сессию из хранилища

Особенности:

• Сервер хранит состояние всех активных сессий.
• Браузер сам управляет куки (автоматически отправляет, соблюдает атрибуты).
• При logout — сессия удаляется и токен становится недействительным.

Cookies: что нужно знать тестировщику

Cookie — небольшой фрагмент данных, хранящийся в браузере и автоматически отправляемый серверу.

Важные атрибуты cookie:

Token-based аутентификация (JWT)

Современный stateless подход (подробно разбирался в уроке про stateless):

1. POST /login → сервер возвращает JWT-токен в теле ответа
2. Клиент сохраняет токен (localStorage или cookie)
3. GET /profile → Authorization: Bearer eyJhbGci...
4. POST /logout → клиент удаляет токен локально (сервер не хранит)

Нюанс logout при JWT: так как сервер ничего не хранит, «настоящий logout» требует дополнительных механизмов (blacklist токенов или короткий срок жизни).

OAuth2 — делегированная авторизация

OAuth2 позволяет входить через сторонние сервисы (Google, GitHub, VK):

1. Пользователь нажимает «Войти через Google»
2. Редирект на Google → пользователь логинится там
3. Google перенаправляет обратно с authorization code
4. Приложение обменивает code на access_token
5. Приложение использует token для запросов к Google API

Тестирование аутентификации: чеклист

Позитивные сценарии

[ ] Вход с правильными логином и паролем → 200, получен токен/сессия
[ ] Доступ к защищённому ресурсу с валидным токеном → 200
[ ] Выход из системы → последующий запрос с тем же токеном отклоняется

Негативные сценарии

[ ] Вход с неверным паролем → 401 (не 403, не 200 с ошибкой в теле)
[ ] Запрос без токена → 401
[ ] Запрос с истёкшим токеном → 401
[ ] Запрос с подделанным токеном → 401
[ ] Доступ к чужим ресурсам (другой userId в URL) → 403 или 404

Проверка авторизации (ролевой доступ)

[ ] User (обычный) → нет доступа к /admin → 403
[ ] Admin → есть доступ к /admin → 200
[ ] Менеджер читает данные другого менеджера → должен быть запрет?

Частые ошибки тестировщиков

• Путать 401 и 403. 401 — нет аутентификации, 403 — нет прав.
• Не тестировать истечение токена. Это реальный сценарий (пользователь долго не заходил).
• Не тестировать IDOR. IDOR (Insecure Direct Object Reference) — доступ к чужим данным через перебор ID. GET /users/43 вместо GET /users/42 — видит ли пользователь чужие данные?
• Не проверять logout. После выхода старый токен должен быть недействителен.

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

• Аутентификация — кто ты? Авторизация — что тебе можно?
• Session-based — сервер хранит сессию, клиент посылает session_id через cookie.
• JWT — stateless токен, клиент сам хранит и передаёт его в каждом запросе.
• OAuth2 — делегированная авторизация через сторонний сервис.
• Всегда тестируй: без токена (401), с истёкшим (401), с недостаточными правами (403), доступ к чужим ресурсам.