A07:2025 Сбои аутентификации

Общие сведения.

Сбои аутентификации сохраняют 7-е место с небольшим изменением названия, точнее отражающим 36 CWE данной категории. Несмотря на преимущества стандартизированных фреймворков, категория удержала 7-ю позицию с 2021 года. Среди значимых CWE: CWE-259 Использование жёстко заданного пароля, CWE-297: Неправильная проверка сертификата при несоответствии хоста, CWE-287: Неправильная аутентификация, CWE-384: Фиксация сессии и CWE-798 Использование жёстко заданных учётных данных.

Таблица оценок.

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
36	15,80%	2,92%	100,00%	37,14%	7,69	4,44	1 120 673	7 147

Описание.

Данная уязвимость присутствует, когда злоумышленник способен убедить систему признать недопустимого или некорректного пользователя легитимным. Слабые места аутентификации могут существовать, если приложение:

Допускает автоматизированные атаки, такие как подстановка учётных данных (credential stuffing), когда злоумышленник располагает списком скомпрометированных логинов и паролей. В последнее время этот тип атак расширился до гибридных атак (также называемых атаками с распылением паролей), когда злоумышленник использует вариации или модификации утечённых учётных данных, например пробуя Password1!, Password2!, Password3! и т.д.
Допускает брутфорс или другие автоматизированные атаки, которые не блокируются своевременно.
Допускает использование стандартных, слабых или общеизвестных паролей, таких как «Password1» или «admin»/«admin».
Позволяет пользователям создавать новые учётные записи с уже известными скомпрометированными учётными данными.
Допускает использование слабых или неэффективных механизмов восстановления учётных данных и сброса пароля, таких как «секретные вопросы», которые не могут быть надёжными.
Использует хранение паролей в открытом тексте, зашифрованном виде или с использованием слабого хеширования (см. A04:2025-Криптографические сбои).
Не имеет или имеет неэффективную многофакторную аутентификацию.
Допускает слабые или неэффективные резервные варианты при недоступности многофакторной аутентификации.
Раскрывает идентификатор сессии в URL, скрытом поле или другом небезопасном месте, доступном клиенту.
Повторно использует тот же идентификатор сессии после успешного входа.
Не выполняет корректную аннуляцию пользовательских сессий или токенов аутентификации (прежде всего SSO-токенов) при выходе из системы или истечении периода бездействия.
Не проверяет должным образом область применения и целевую аудиторию предоставленных учётных данных.

Как предотвратить.

По возможности внедряйте и принудительно применяйте многофакторную аутентификацию для защиты от автоматизированных атак credential stuffing, брутфорса и повторного использования похищенных учётных данных.
По возможности поощряйте и разрешайте использование менеджеров паролей, чтобы помочь пользователям делать лучший выбор.
Не поставляйте и не развёртывайте системы со стандартными учётными данными, особенно для административных пользователей.
Внедрите проверку слабости паролей, например сравнивая новые или изменённые пароли с 10 000 наиболее распространённых плохих паролей.
При создании новой учётной записи и смене пароля проверяйте их по спискам известных скомпрометированных учётных данных (например, используя haveibeenpwned.com).
Приведите политику длины, сложности и ротации паролей в соответствие с руководством NIST 800-63b, раздел 5.1.1 для запомненных секретов или другими современными политиками паролей, основанными на доказательствах.
Не принудительно ротируйте пароли людей, если только вы не подозреваете взлом. При подозрении на взлом немедленно принудите к сбросу паролей.
Защитите конечные точки регистрации, восстановления учётных данных и API от атак перечисления учётных записей, используя одинаковые сообщения для всех исходов («Неверное имя пользователя или пароль.»).
Ограничивайте или постепенно задерживайте неудачные попытки входа, но будьте осторожны, чтобы не создать сценарий отказа в обслуживании. Журналируйте все сбои и оповещайте администраторов при обнаружении или подозрении на credential stuffing, брутфорс или другие атаки.
Используйте безопасный серверный встроенный менеджер сессий, генерирующий новый случайный идентификатор сессии с высокой энтропией после входа. Идентификаторы сессий не должны быть в URL, должны храниться в защищённых cookies и аннулироваться при выходе, по истечении времени бездействия и абсолютного таймаута.
В идеале используйте готовую проверенную систему для обработки аутентификации, управления идентификаторами и сессиями. Передавайте этот риск при каждой возможности, приобретая и используя закалённую и хорошо протестированную систему.
Проверяйте предполагаемое использование предоставленных учётных данных, например для JWT валидируйте утверждения aud, iss и области действия.

Примеры сценариев атак.

Сценарий №1: Credential stuffing — использование списков известных комбинаций логин/пароль — сейчас очень распространённая атака. Всё чаще злоумышленники «наращивают» или иным образом корректируют пароли на основе типичного поведения людей, например заменяя 'Winter2025' на 'Winter2026' или 'ILoveMyDog6' на 'ILoveMyDog7'. Такая корректировка попыток называется гибридной атакой с подстановкой учётных данных или атакой с распылением паролей и может быть даже эффективнее традиционной версии. Если приложение не реализует защиту от автоматизированных угроз или credential stuffing, оно может использоваться как «оракул паролей».

Сценарий №2: Большинство успешных атак на аутентификацию происходят из-за продолжения использования паролей как единственного фактора аутентификации. Ротация паролей и требования к сложности, когда-то считавшиеся лучшими практиками, побуждают пользователей повторно использовать пароли и создавать слабые пароли. Организациям рекомендуется прекратить эти практики согласно NIST 800-63 и применять многофакторную аутентификацию на всех важных системах.

Сценарий №3: Таймауты сессий приложения реализованы некорректно. Пользователь использует общедоступный компьютер для доступа к приложению и вместо выхода просто закрывает вкладку браузера. Аналогичный пример — если SSO-сессия не может быть закрыта единым выходом (SLO). Злоумышленник, использующий тот же браузер после того, как жертва считает, что вышла из системы, может получить доступ к её учётной записи. Та же проблема может возникнуть в офисах и предприятиях, когда конфиденциальное приложение не было должным образом закрыто и коллега получает временный доступ к незаблокированному компьютеру.