Такие уязвимости находят через перебор пользователей и паролей. И если система возвращает разные сообщения об ошибках при неверном логине и пароле — это позволяет определить, какие логины существуют. Дальше идёт подбор. Через форму восстановления пароля можно отправить десятки писем с подменой адресов и ссылок. Разные ответы сервера также можно найти и в форме восстановления пароля, там в поле в основном вводится почта пользователя, соответственно можно собрать список почт для использования в фишинге.

Форма восстановления пароля может таить в себе ещё и возможность DOS-атак.

Если разработчики не предусмотрели ограничения, злоумышленник может отправлять огромное количество писем на один и тот же адрес, модифицируя его (например, user@mail.com, user+1@mail.com, user+2@mail.com). А если на сайте есть ещё и уязвимость, связанная с обработкой заголовка Host, ситуация становится ещё серьёзнее: атакующий может подменить адрес сайта в письме. Тогда пользователь получит письмо со ссылкой на внешний, подконтрольный злоумышленнику ресурс — и передаст свой код подтверждения не тому, кому нужно.

Как защититься

Чтобы защитить форму аутентификации от уязвимостей, важно реализовать несколько ключевых мер:

🔺Унифицировать ответы сервера при неверных логине и пароле — сообщения об ошибке не должны давать понять, существует ли такой пользователь.

🔺Ввести ограничения на количество попыток входа — использовать rate limiting, капчу или блокировку IP/учётки.

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

🔺Защитить форму восстановления пароля от enumeration и флуда — проверять частоту запросов, использовать токены с ограничением по времени и одноразовые ссылки.

🔺Исключить возможность Host header injection — проверять заголовок Host на соответствие допустимому списку доменов при генерации ссылок в письмах.