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