Представим вполне обычную задачу. В продукте нужно проверить восстановление пароля.

Пользователь вводит email, получает письмо, переходит по ссылке и задаёт новый пароль. Ссылка действует час и после использования должна перестать работать. Никакой экзотики. Такую форму мы видели сотни раз.

Тестировщик тоже подошёл к задаче без халтуры. Проверил, что письмо приходит на зарегистрированный адрес. Убедился, что по неизвестному email система не раскрывает наличие аккаунта. Попробовал просроченную ссылку, невалидный пароль и повторный переход по уже использованной ссылке.

Старый пароль после сброса не работал. Новый работал. Все тесты прошли, задачу выпустили.

Казалось бы, что здесь ещё можно сломать?

Через 10 минут пароль снова не подошел

Спустя несколько дней в поддержку написал пользователь. Он восстановил пароль, вошёл в аккаунт и спокойно продолжил работу. Примерно через десять минут его выбросило из системы.

Новый пароль больше не подходил.

В журнале безопасности нашли две смены пароля. Первую выполнил сам пользователь. Вторую выполнил кто‑то с другого IP‑адреса спустя восемь минут.

Сначала всё выглядело довольно очевидно. Возможно, украли новую сессию или получили доступ к почте. Но обнаружилась ещё одна деталь.

Перед восстановлением пользователь дважды нажал кнопку «Восстановить пароль». Первое письмо задержалось, поэтому через несколько минут он запросил второе. В итоге на почту пришли две ссылки.

Пользователь открыл более свежее письмо, задал новый пароль и вошёл в аккаунт.

А первая ссылка так и осталась лежать в почте.

Что здесь не проверили?

Попробуйте пока не читать дальше и восстановить последовательность самостоятельно.

Тестировщик ведь проверил одноразовость ссылки. После смены пароля открыть её повторно было нельзя. Срок действия тоже работал. Старый пароль система больше не принимала.

Тогда откуда взялась вторая смена?

Полезно задать себе три вопроса.

1. Что происходит со старой ссылкой после выпуска новой?

2. Что происходит со всеми остальными ссылками после успешной смены пароля?

3. Одноразовая ссылка является свойством конкретного токена или всей операции восстановления?

Ответ

Что об этом говорит OWASP

OWASP рассматривает восстановление пароля не как вспомогательную форму, а как альтернативный механизм аутентификации. Фактически пользователь получает доступ к аккаунту без предъявления действующего пароля. Поэтому такой процесс не должен быть слабее обычного входа, иначе атакующий просто обойдёт основную защиту через recovery flow.

Токен из письма в этой модели становится временным подтверждением личности. OWASP рекомендует генерировать такие токены криптографически стойким способом, обеспечивать достаточную энтропию, безопасно хранить их на стороне сервера, связывать с конкретным пользователем, ограничивать срок действия и запрещать повторное использование. Для ссылок восстановления также нужно использовать HTTPS, защищаться от перебора и не допускать утечки токена через заголовок Referer, сторонние скрипты или некорректно сформированный домен.

Отдельное внимание OWASP уделяет сопутствующим рискам. Ответ системы и время его формирования не должны позволять определить, зарегистрирован ли указанный email. Количество запросов на восстановление необходимо ограничивать, иначе механизм можно использовать для автоматизированных атак или массовой отправки писем. После успешной смены пароля пользователя следует уведомить, а существующие сессии нужно либо инвалидировать автоматически, либо предложить пользователю завершить их.

При этом OWASP не устанавливает единственное обязательное правило для нескольких одновременно выпущенных ссылок. Например, стандарт напрямую не требует аннулировать первую ссылку сразу после создания второй. Такое поведение зависит от модели угроз и требований продукта.

Но после успешной смены пароля старый действующий токен продолжает предоставлять альтернативный способ изменить учётные данные. Пока он не истёк, восстановление доступа нельзя считать завершённым. Поэтому безопасная реализация должна явно определять жизненный цикл всей совокупности токенов пользователя, а не только каждого токена по отдельности.

На практике это обычно означает, что успешная смена пароля инвалидирует все незавершённые запросы восстановления для этого аккаунта. Более строгая модель может отзывать предыдущие токены уже при создании нового. Это не дословное требование OWASP, а архитектурный вывод из его принципов одноразовости токена, ограничения срока действия и недопустимости сохранения альтернативного пути к компрометации аккаунта.

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

На открытых уроках OTUS можно потренироваться находить такие разрывы на практике:

• 21 июля в 20:00 — «UI и API тестирование с Java и Playwright».
  _{Разберём, как объединять проверки интерфейса и API, управлять тестовыми данными и автоматизировать сценарии, которые состоят из нескольких зависимых шагов.}

• 23 июля в 20:00 — «Тестирование интернет‑магазина: от каталога до оплаты».
  _{Посмотрим, как проверять сквозные пользовательские сценарии и находить ошибки, которые не видны при изолированном тестировании отдельных экранов.}

• 30 июля в 20:00 — «API и UI тестирование с Playwright на Python».
  _{Поговорим о том, как воспроизводить сложные цепочки действий через API и интерфейс и проверять, что состояние системы меняется именно так, как задумано.}

Участие бесплатное, но требуется регистрация.

Больше бесплатных уроков июля смотрите в дайджесте.