API9:2019 Ненадлежащее Управление Активами

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

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

API может быть уязвимым, если:

Назначение API хоста неясно, а также нет четких ответов на следующие вопросы:
В каком окружении запущен API (например, production, staging, test, development)?
Каким должен быть сетевой доступ к API (например, общедоступным, внутренним, для партнеров)?
Какая версия API запущена?
Какие данные собираются и обрабатываются API (например, персональные данные)?
Каков поток движения данных?
Документация отсутствует или не обновляется.
Отсутствует план вывода из эксплуатации предыдущих версий API.
Инвентаризация хостов не проводится, или ее результаты устарели.
Инвентаризация интегрированных внутренних или сторонних сервисов не проводится, или ее результаты устарели.
Старые или предыдущие версии API функционируют без обновлений.

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

Сценарий #1

После переработки своих приложений локальный поисковый сервис оставил доступ к старой версии API (api.someservice.com/v1) без надлежащих мер защиты и с доступом к базе данных пользователей. Тестируя одну из последних выпущенных версий приложения, злоумышленник нашел адрес API (api.someservice.com/v2). Заменив v2 на v1 в URL, злоумышленник получил доступ к старому незащищенному API, предоставляющему доступ к персональным данным более 100 миллионов пользователей.

Сценарий #2

Социальная сеть внедрила механизм ограничения количества запросов, не позволяющий злоумышленнику подобрать токен для сброса пароля. Этот механизм не был внедрен непосредственно в код API, а использовался в качестве отдельного компонента между клиентом и официальным API (www.socialnetwork.com). Исследователь нашел бета версию API (www.mbasic.beta.socialnetwork.com), использующую тот же API, включая механизм сброса пароля, но без механизма ограничения количества запросов. Исследователь смог сбросить пароль любого пользователя, перебирая все возможные варианты кода из 6 цифр.

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

Проводите инвентаризацию хостов API и документируйте важные аспекты каждого из них: окружение (например, production, staging, test, development), каким должен быть сетевой доступ (например, общедоступным, внутренним, для партнеров) и версию API.
Проводите инвентаризацию интегрированных сервисов и документируйте важные аспекты каждого из них: роль в системе, какие данные участвуют в обмене (потоки данных), какая степень критичности этих данных.
Документируйте все аспекты API: аутентификацию, ошибки, перенаправления, ограничение количества запросов, политику разделения ресурсов между источниками (CORS) и точки входа, включая параметры, запросы и ответы.
Создавайте документацию автоматически, используя общедоступные стандарты. Включайте создание документации в CI/CD.
Предоставьте документацию тем, кто имеет право доступа к API.
Используйте внешние меры защиты, например, API security firewalls на всех доступных версиях API, а не только на текущей версии в production.
Избегайте использования данных с production системы в API на базе не production окружения. Если такого использования невозможно избежать, защищайте этот API аналогично используемым в production.
Когда новая версия API включает улучшения, связанные с безопасностью, проводите анализ рисков для принятия решения о действиях по снижению рисков в старых версиях, например, переносу улучшения в старые версии без нарушения совместимости, или отключению старой версии и переводу всех клиентов на новую.