Главная » Инф-ая безопасность » A07:2021- Ошибки идентификации и аутентификации

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

A07:2021- Ошибки идентификации и аутентификации
Инф-ая безопасность
12 ноябрь 2021
0

Обзор


Ранее называлась Некорректная аутентификация и опустилась со второго места на седьмое место, теперь она включает в себя 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: Тайм-ауты сеанса приложения установлены неправильно. Пользователь использует общедоступный компьютер для доступа к приложению. Вместо того, чтобы выбрать "выход", пользователь просто закрывает вкладку браузера и уходит. Злоумышленник использует тот же браузер час спустя, и пользователь все еще проходит аутентификацию.

Об авторе
admin Пользователь не указал информацию о себе
Ctrl
Enter
Заметили ошЫбку
Выделите текст и нажмите Ctrl+Enter
4 059
0
+13
Комментарии (0)