Сервис позволяет менять пароль из активной сессии без повторного ввода учётных данных. Какой тест подтвердит, что критическая операция защищена повторной аутентификацией?
Нужно проверить, что одной ранее созданной сессии недостаточно для смены пароля: после запроса на изменение сервис должен потребовать повторное подтверждение личности, например текущий пароль или другой предусмотренный фактор. Тест следует выполнить с действительной, но давно созданной сессией и убедиться, что без этого подтверждения пароль не меняется.
Активная сессия обычно предназначена для удобного доступа к функциям приложения, но сама по себе может быть украдена через вредоносное расширение, заражённое устройство или утечку токена. Поэтому для особенно опасных операций применяют повторную аутентификацию — защитный слой поверх уже установленной сессии.
Изначальная проблема такого подхода — ограничить ущерб от временно скомпрометированной сессии. Даже если злоумышленник получил доступ к интерфейсу пользователя, ему дополнительно требуется подтвердить владение учётными данными или вторым фактором.
Смена пароля изменяет основной способ входа в учётную запись. Если она разрешена только по признаку действующей сессии, похититель этой сессии может установить собственный пароль, вытеснить настоящего пользователя и сохранить контроль над аккаунтом.
Тест должен учитывать не только экран интерфейса, но и серверную проверку. Нельзя считать защиту достаточной, если поле повторного подтверждения скрыто клиентом, проверяется только браузером или требуется лишь для одного варианта запроса.
Создайте обычную учётную запись, войдите в неё и сохраните сессию. Затем проверьте попытку смены пароля без повторного ввода текущего пароля или без другого обязательного фактора. Ожидаемый результат — операция отклонена, новый пароль не активирован, а ответ не раскрывает лишних сведений о механизме защиты.
После этого повторите проверку с корректным подтверждением и убедитесь, что операция выполняется только при его успешной проверке. Проверьте также истечение времени повторной аутентификации: отметка о недавно подтверждённой личности должна действовать ограниченный период, а не бессрочно.
Важно проверить каждый доступный путь к операции: веб-форму, альтернативный метод HTTP-запроса, мобильный клиент и административный интерфейс, если они существуют. Сервер должен принимать решение независимо от состояния элементов интерфейса и не полагаться на переданное клиентом значение вроде признака «проверено».
Повторная аутентификация не заменяет управление сессиями, защиту от CSRF и корректную авторизацию. После смены пароля желательно отдельно проверить отзыв старых сессий или явное информирование пользователя о политике их сохранения: это самостоятельное требование, зависящее от модели угроз.
В системе смена пароля была доступна из профиля и требовала только текущей авторизованной сессии. Рассматривались три варианта: оставить поведение без изменений, запрашивать текущий пароль при каждой смене или требовать подтверждение второго фактора после недавнего входа.
Первый вариант был простым, но не защищал от кражи сессии. Запрос текущего пароля давал сильную защиту, однако ухудшал удобство и не помогал, если пароль уже скомпрометирован. Подтверждение второго фактора лучше снижало риск захвата аккаунта, но зависело от его доступности и требовало резервного сценария восстановления.
Выбрали обязательный ввод текущего пароля для обычной смены и дополнительный второй фактор для чувствительных учётных записей. Тестировщик подтвердил серверную проверку обоих условий, проверил повторное использование старой сессии и убедился, что запрос без подтверждения не изменяет пароль даже при прямом обращении к серверу.
Нет, это зависит от модели угроз. Если текущий пароль уже украден, повторный ввод не защищает аккаунт от злоумышленника; для высокорисковых операций нужен дополнительный фактор или иной независимый способ подтверждения личности.
Не всегда это безусловное требование, но сохранение старых сессий должно быть осознанной политикой. Тестировщик должен проверить фактическое поведение, наличие понятного уведомления и возможность пользователю завершить остальные сессии; автоматический отзыв снижает риск, но может прервать работу легитимных устройств.
Только если сервер явно связывает его с конкретной чувствительной операцией и ограничивает срок действия такого подтверждения. Простого факта наличия активной сессии недостаточно: украденная сессия как раз позволяет обойти проверку, если приложение не различает обычную аутентификацию и недавно подтверждённое действие.