API7:2019 Ошибки Настроек Безопасности

Источники угроз/Векторы атак	Недостатки безопасности	Последствия
Зависит от API : Сложность эксплуатации 3	Распространенность 3 : Сложность обнаружения 3	Технические последствия 2 : Зависит от бизнеса
Злоумышленники часто пытаются найти незакрытые уязвимости, распространенные точки входа или незащищенные файлы и папки, чтобы получить информацию о системе или неавторизованный доступ к ней.	Ошибка настроек безопасности может произойти на любом уровне API: от сетевого уровня до уровня приложения. Существуют автоматизированные инструменты для обнаружения и эксплуатации таких ошибок конфигурации, как ненужные (забытые) сервисы или использование устаревших параметров.	Ошибки настроек безопасности могут не только раскрыть конфиденциальные данные пользователей, но и данные о системе, что потенциально может привести к её полной компрометации.

Как определить, является ли API уязвимым?

API уязвим, если:

Должные настройки безопасности отсутствуют на каком-либо уровне приложения, а также если права доступа к облачным сервисам некорректно настроены.
Используется устаревшая система, или не установлены новейшие исправления по безопасности.
Активен излишний функционал (например, неиспользуемые HTTP методы).
Не используется протокол TLS (Transport Layer Security).
Директивы безопасности не отправляются клиентским приложениям (например, Заголовки Безопасности).
Политика разделения ресурсов между источниками (Cross-Origin Resource Sharing) отсутствует или некорректно настроена.
Сообщения об ошибках включают детальную информацию или раскрывают критичные данные.

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

Сценарий #1

Злоумышленник в корне директории сервера находит файл .bash_history, содержащий команды, которые использовала команда DevOps для доступа к API:

$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='

Злоумышленник также может найти другие незадокументированные точки входа API, используемые только командой DevOps.

Сценарий #2

Для атаки на конкретный сервис злоумышленник использует популярный поисковик, чтобы найти компьютеры, напрямую доступные из сети Интернет. Злоумышленник находит сервер, на котором запущена популярная система управления базой данных, доступная на стандартном порте. На сервере используется стандартная конфигурация, не предполагающая аутентификации, что позволяет злоумышленнику получить доступ к миллионам записей с персональными данными, личными предпочтениями и аутентификационными данными.

Сценарий #3

Анализируя трафик мобильного приложения, злоумышленник обнаруживает, что не весь HTTP трафик защищен (например, с помощью TLS). В частности, не защищено скачивание изображений профиля. Поскольку взаимодействие пользователя с приложением бинарно (да или нет, свайп влево или вправо, и так далее), несмотря на шифрование трафика, злоумышленник может найти закономерности в параметрах ответов API (например, размер ответа на свайп влево больше, чем на свайп вправо), которые он в свою очередь может использовать для отслеживания действий и предпочтений пользователя.

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

Жизненный цикл API должен включать в себя:

Повторяемый процесс усиления настроек безопасности, ведущий к более быстрому и простому развертыванию должным образом защищенного окружения.
Задачу по обзору и обновлению конфигурации на всех уровнях API. Обзор должен включать в себя файлы оркестрации, компоненты API и облачных сервисов (например, права доступа в S3 bucket).
Защищенный канал связи при доступе к статическим ресурсам.
Автоматизированный процесс, проводящий постоянную оценку эффективности настроек и параметров во всех окружениях.

Кроме того:

Для предотвращения отправки злоумышленникам подробных сообщений об ошибках и другой критичной информации, если это возможно, определите схемы данных всех ответов API и обеспечьте проверку этих ответов по схемам, включая сообщения об ошибках.
Убедитесь, что API доступно только с использованием заданного списка HTTP методов. Любые другие методы HTTP должны быть отключены (например, HEAD).
API, клиентами которых подразумеваются браузерные клиентские приложения, должны иметь корректно настроенную политику разделения ресурсов между источниками (Cross-Origin Resource Sharing).