Тестирование аутентификации и сессий

Аутентификация: парадная дверь вашего приложения #

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

Этот урок охватывает тестирование потоков аутентификации (вход, регистрация, восстановление пароля) и управление сессиями (как приложение отслеживает вашу личность после входа).

Тестирование потока входа #

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

Начните с очевидного: валидные учётные данные должны работать.

• Вход с корректным email и паролем
• Проверка перенаправления на правильную страницу
• Проверка отображения имени или аватара пользователя в UI
• Проверка создания сессии (проверить cookies в DevTools)

Невалидные учётные данные #

Критическое замечание по безопасности: Сообщение об ошибке при неверном email и при неверном пароле должно быть одинаковым. Разные сообщения позволяют злоумышленникам перечислять существующие аккаунты.

Защита от перебора #

Попробуйте войти с неправильными паролями многократно:

1. После 3-5 неудачных попыток, показывает ли система CAPTCHA?
2. После 10+ попыток, блокируется ли аккаунт или ограничивается частота?
3. Есть ли период охлаждения? Какой длительности?
4. Блокировка применяется к IP, к аккаунту или к обоим?

Социальный вход (OAuth) #

Если приложение поддерживает вход через Google, GitHub, Facebook:

• Корректно ли работает поток OAuth?
• Что происходит, если пользователь отказывает в разрешении?
• Сопоставляется ли email из OAuth с существующим аккаунтом?
• Что происходит, если социальный провайдер недоступен?

Тестирование потока регистрации #

Создание аккаунта #

• Валидная регистрация со всеми обязательными полями
• Дублирующийся email — должен отклоняться с понятным сообщением
• Требования к сложности пароля — тестировать чуть ниже каждого требования
• Подтверждение email — работает ли ссылка подтверждения?
• Срок действия ссылки — истекает ли через разумное время?

Подтверждение email #

1. Зарегистрируйте новый аккаунт
2. Проверьте, что письмо подтверждения приходит
3. Перейдите по ссылке — аккаунт должен активироваться
4. Перейдите по той же ссылке снова — должно показать «уже подтверждено»
5. Попробуйте войти до подтверждения — должно показать соответствующее сообщение

Тестирование восстановления пароля #

Поток «Забыли пароль» #

1. Запросите сброс пароля для валидного email
2. Убедитесь, что письмо приходит в разумное время
3. Перейдите по ссылке сброса — должна показаться форма сброса
4. Установите новый пароль — должно успешно
5. Войдите с новым паролем — должно работать
6. Войдите со старым паролем — должно не работать
7. Перейдите по ссылке сброса снова — должна быть просрочена

Граничные случаи безопасности #

Управление сессиями #

Создание и хранение сессий #

После входа проверьте:

• Создана cookie сессии
• Cookie имеет флаг Secure (только HTTPS)
• Cookie имеет флаг HttpOnly (недоступна для JavaScript)
• Cookie имеет атрибут SameSite
• ID сессии достаточно длинный и случайный (минимум 128 бит)
• ID сессии меняется после входа (предотвращение session fixation)

Таймаут сессии #

• Таймаут бездействия: После X минут бездействия сессия истекает
• Абсолютный таймаут: После Y часов независимо от активности сессия истекает
• Поведение при таймауте: Что происходит при истечении сессии? Перенаправление на вход? Модальное окно? Потеря несохранённой работы?

Продвинутое тестирование аутентификации #

Параллельные сессии #

Проверьте, что происходит, когда один пользователь входит с нескольких мест:

1. Вход в Браузере А
2. Вход в Браузере Б с тем же аккаунтом
3. Выполните действие в Браузере А — сессия ещё действительна?
4. Ограничивает ли приложение параллельные сессии?
5. Если сессии ограничены, какая завершается — старая или новая?

Функциональность «Запомнить меня» #

Если форма входа имеет чекбокс «Запомнить меня»:

• Как долго длится постоянная сессия? (Обычно 30 дней)
• Используется ли отдельный постоянный токен (не cookie сессии)?
• Может ли пользователь отозвать все запомненные сессии из настроек?
• Переживает ли «Запомнить меня» перезапуск браузера?
• Инвалидируется ли постоянный токен при смене пароля?

Многофакторная аутентификация (MFA) #

Если приложение поддерживает MFA:

• Работает ли с приложениями-аутентификаторами (TOTP)?
• Работает ли с SMS-кодами?
• Что происходит с просроченным кодом?
• Что происходит при 3+ неправильных кодах?
• Можно ли обойти MFA, манипулируя запросом?
• Предоставляются ли резервные коды и работают ли они?

Упражнение: Аудит безопасности аутентификации #

Проведите полный аудит аутентификации веб-приложения:

1. Регистрация: Создайте аккаунт, проверьте дубликаты, верификацию email
2. Вход: Проверьте валидные/невалидные данные, сообщения об ошибках на утечку перечисления
3. Сессия: Проверьте cookies на флаги безопасности (Secure, HttpOnly, SameSite)
4. Таймаут: Дождитесь истечения сессии, проверьте поведение
5. Сброс пароля: Пройдите весь поток, проверьте истечение ссылки
6. Параллельные сессии: Войдите из двух браузеров одновременно
7. Выход: Проверьте уничтожение сессии — нажмите «Назад» после выхода

Тестирование выхода #

Выход часто недостаточно тестируется:

1. Нажмите «Выход» — проверьте перенаправление на страницу входа
2. Нажмите кнопку «Назад» — НЕ должен показывать аутентифицированный контент
3. Попробуйте напрямую обратиться к аутентифицированному URL — должен перенаправить на вход
4. Проверьте, что cookie сессии удалена или инвалидирована
5. Проверьте, что серверная сессия уничтожена (не только удаление cookie)
6. На отдельной открытой вкладке — что происходит при попытке выполнить действие?

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

• Аутентификация — наиболее критичная для безопасности функция, тестируйте её исчерпывающе
• Сообщения об ошибках при входе должны быть общими для предотвращения перечисления аккаунтов
• Всегда проверяйте наличие флагов Secure, HttpOnly и SameSite у cookie сессии
• Тестируйте таймаут сессии и по бездействию, и абсолютный
• Ссылки сброса пароля должны истекать и инвалидироваться после использования
• ID сессии должны регенерироваться после входа для предотвращения session fixation
• Выход должен уничтожать сессию на стороне сервера, а не только удалять cookie