СреднийВеб-рискНужна ручная проверкаРиски веб-приложенийВсе материалы о Веб-приложения

Уязвимости восстановления пароля: токены, ссылки и отзыв сессий

Как защитить сброс пароля: одноразовые токены с ограниченным сроком, доверенный домен ссылки и контроль действующих сессий.

Коротко о главном

Чем опасно
Несанкционированная смена пароля.
С чего начать защиту
Генерируйте случайный одноразовый токен, храните его безопасно и ограничьте срок действия.
Как подтвердить
Нужны ручной аудит и проверка реализации. Отсутствие находок во внешнем скане не подтверждает безопасность.
Посмотреть условия проверки
В этой статье
  1. Что это за уязвимость
  2. Когда возникает риск
  3. Возможные последствия
  4. Как защитить приложение
  5. Как безопасно проверить исправление
  6. Оценка риска и границы сканирования
Продукт
Веб-приложения
Оценка риска
Уровень зависит от конфигурации

Как проверить и что учитывать

Нужна ручная проверка

Для подтверждения нужны анализ реализации и проверки на согласованном тестовом контуре. Публикация не означает автоматическое обнаружение этого сценария FindRisk. Не делайте вывод о наличии уязвимости только по одному внешнему признаку: подтвердите результат в настройках и версии компонента.

Что нужно для подтверждения

Используйте отдельный тестовый аккаунт: проверьте истечение срока, повторное и параллельное применение токена, привязку к аккаунту и домен в письме. Завершение операции не должно автоматически создавать незащищённую сессию.

Ограничения вывода

  • Внешний ответ не раскрывает все роли, обработчики и настройки внутренних компонентов.
  • Используйте только свои системы или письменное разрешение владельца; нагрузочные проверки согласуйте отдельно.

Что это за уязвимость

Восстановление пароля — альтернативный путь управления аккаунтом. Предсказуемый, повторно используемый или неверно привязанный токен ослабляет защиту даже при безопасном входе.

Когда возникает риск

Проверьте генерацию и хранение токена, срок действия, привязку к пользователю, параллельное использование и формирование URL письма. Наличие HTTPS само по себе не устраняет эти ошибки.

Возможные последствия

Как защитить сброс пароля: одноразовые токены с ограниченным сроком, доверенный домен ссылки и контроль действующих сессий.

  • Несанкционированная смена пароля.
  • Утечка токена через журналы, аналитику или Referer.

Как защитить приложение

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

  • Генерируйте случайный одноразовый токен, храните его безопасно и ограничьте срок действия.
  • Формируйте HTTPS-ссылку из доверенной конфигурации, а не произвольного Host.
  • Ограничьте частоту запросов, исключите токен из журналов и дайте пользователю отозвать сессии.

Как безопасно проверить исправление

Используйте отдельный тестовый аккаунт: проверьте истечение срока, повторное и параллельное применение токена, привязку к аккаунту и домен в письме. Завершение операции не должно автоматически создавать незащищённую сессию.

Оценка риска и границы сканирования

Средний уровень — ориентировочная редакционная оценка, не CVSS подтверждённой находки. Для конкретной системы приоритет зависит от доступных данных, полномочий и компенсирующих мер; последствия могут быть значительно серьёзнее.

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

Как проходит проверка

Для подтверждения нужны анализ реализации и проверки на согласованном тестовом контуре. Публикация не означает автоматическое обнаружение этого сценария FindRisk. Автоматический результат показывает внешний признак риска и требует проверки специалистом с учётом конкретной конфигурации.

Проверить другие внешние риски

Что делать после обнаружения

  • Зафиксируйте затронутый сценарий и сохраните журналы без токенов и персональных данных.
  • Ограничьте проблемный обработчик, оцените доступные данные и назначьте владельца исправления.
  • Устраните первопричину и добавьте регрессионную проверку на тестовых данных.

Частые вопросы

Что означает риск «Уязвимости восстановления пароля»?

Как защитить сброс пароля: одноразовые токены с ограниченным сроком, доверенный домен ссылки и контроль действующих сессий.

Можно ли подтвердить проблему только внешней проверкой?

Для подтверждения нужны анализ реализации и проверки на согласованном тестовом контуре. Публикация не означает автоматическое обнаружение этого сценария FindRisk. Итог нужно сопоставить с конфигурацией, версиями и правами доступа на вашем сайте.

Что сделать в первую очередь?

Генерируйте случайный одноразовый токен, храните его безопасно и ограничьте срок действия.

Источники

Разобраться по шагам

Больше материалов о рисках и защите сайтов — в каталоге уязвимостей.

Критический

GitLab: сброс пароля на чужой email

На своём GitLab CE/EE 16.1–16.7 письмо сброса пароля могло уйти на неподтверждённый email. Обновите инстанс и проверьте учётные записи. GitLab.com это не затрагивает.

Средний

Утечка через Referer

Как приватные адреса и токены попадают в Referer, историю и журналы и почему одной Referrer-Policy недостаточно для защиты секретов в URL.

Средний

Ошибки MFA

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

Средний

Account Enumeration

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

Средний

Host Header Injection

Почему нельзя строить доверенные ссылки из произвольного Host или X-Forwarded-Host и как настроить допустимые домены приложения.

Высокий

Завершение сессии

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