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