A07:2021- Ошибки идентификации и аутентификации

Обзор

Ранее называлась Некорректная аутентификация и опустилась со второго места на седьмое место, теперь она включает в себя CWE, которые больше связаны с ошибками идентификации. Известные CWE: CWE-297: Неправильная проверка сертификата с несоответствием хоста, CWE-287: Неправильная аутентификация и CWE-384: Фиксация сеанса.

Описание

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

• Разрешает автоматические атаки, такие как ввод учетных данных, когда у злоумышленника есть список действительных имен пользователей и паролей.
• Допускает перебор или другие автоматические атаки.
• Разрешает стандартные, слабые или хорошо известные пароли, например, "Password1" or "admin/admin". Разрешает использование паролей по умолчанию, слабых или хорошо известных паролей, таких как "Password1" или " admin/admin".
• Использует слабые или неэффективные процессы восстановления учетных данных и забытых паролей, такие как "ответы, основанные на знаниях" (Вопрос-Ответ), которые нельзя сделать безопасными.
• Использует хранилища данных с простым текстом, зашифрованными или слабо хэшированными паролями (см. A02:2021 - Криптографические сбои).
• Имеет отсутствующую или неэффективную многофакторную аутентификацию.
• Предоставляет идентификатор сеанса в URL-адресе.
• Использует повторный идентификатор сеанса после успешного входа в систему.
• Неправильно аннулирует идентификаторы сеансов. Сеансы пользователей или токены аутентификации (в основном токены единого входа (SSO)) не считаются недействительными во время выхода из системы или периода бездействия.

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

• Там, где это возможно, внедряйте многофакторную аутентификацию, чтобы предотвратить автоматический ввод учетных данных, перебор и атаки на повторное использование украденных учетных данных.
• Не отправляйте и не развертывайте учетные данные по умолчанию, особенно для пользователей с правами администратора.
• Внедряйте слабые проверки паролей. Например, проверка новых или измененных паролей по списку из 10 000 худших.
• Согласовать длину пароля, сложность и политики ротации с N.
• Изучите Рекомендации Национального института стандартов и технологий (NIST) 800-63b в разделе 5.1.1 для запоминания секретов или других современных, основанных на фактических данных политик паролей.
• Убедитесь, что регистрация, восстановление учетных данных и пути API защищены от атак с перечислением учетных записей, используя одни и те же сообщения для всех результатов.
• Ограничивайте или все чаще откладывайте неудачные попытки входа в систему, но будьте осторожны, чтобы не создать сценарий отказа в обслуживании. Регистрируйте все сбои и предупреждайте администраторов при обнаружении вброса учетных данных, переборов или других атак.
• Используйте защищенный встроенный менеджер сеансов на стороне сервера, который генерирует новый случайный идентификатор сеанса с высокой энтропией после входа в систему. Идентификатор сеанса не должен содержаться в URL-адресе, надежно храниться и быть недействительным после выхода из системы, простоя и абсолютных тайм-аутов.

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

Сценарий №1: Вброс учетных данных, использование списков известных паролей – распространенная атака. Предположим, что приложение не реализует автоматическую защиту от угроз или ввода учетных данных. В этом случае его можно использовать в качестве оракула паролей, чтобы определить, действительны ли учетные данные.

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

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