OWASP ТОП-10: критичные риски безопасности API в 2023 г.

24 августа 2023

API — неотъемлемая составляющая современных ИТ-сервисов, без них не обходится практически ни одно мобильное или веб-приложение. Но поскольку через API проходят огромные объемы данных, а многие API передают конфиденциальные данные, они все чаще становятся объектом кибератак. Прогнозируется, что количество инцидентов с использованием API в качестве точек входа возрастет на 996% к 2030 году!

Чтобы повысить безопасность API, полезно иметь понимание о наиболее уязвимых местах и минимизировать риски исходя из этой информации. В связи с этим предлагаем ознакомиться с обновленным списком ТОП-10 угроз безопасности API от OWASP и рекомендациями по их профилактике.

1. API1:2023 Некорректная авторизация на уровне объекта
2. API2:2023 Некорректная аутентификация пользователей
3. API3:2023 Нарушенная авторизация на уровне свойств объекта
4. API4:2023 Неограниченное потребление ресурсов
5. API5:2023 Нарушенная авторизация на уровне функции
6. API6:2023 Неограниченный доступ к конфиденциальным бизнес-потокам
7. API7:2023 Подделка запроса на стороне сервера
8. API8:2023 Ошибки настроек безопасности
9. API9:2023 Ненадлежащее управление активами
10. API10:2023 Небезопасное использование API
11. Заключение

API1:2023 Некорректная авторизация на уровне объекта

Авторизация на уровне объекта — это механизм, который используется для проверки права доступа пользователя к определенному объекту. При отсутствии проверки на уровне объекта злоумышленники могут использовать конечные точки API, работающие с ID объекта, и получить доступ к критическим данным.

OWASP рекомендует применять надежный механизм авторизации на основе политики пользователей и иерархии в каждой функции, использующей клиентский ввод для доступа к базе данных. Также следует использовать случайные и непредсказуемые значения для ID записей.

API2:2023 Некорректная аутентификация пользователей

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

• Позволяют генерировать ненадежные пароли,
• Не проверяют подлинность токенов,
• Позволяют менять почтовый адрес, пароль и другие данные, не запрашивая пароль,
• Принимают не подписанные JWT-токены или токены с ненадежной подписью,
• Не блокируют учетную запись и не выводят капчу в случае атаки грубой силы на одну и ту же учетную запись,
• Используют ненадежные ключи шифрования и не хешируют пароли.

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

Необходимо провести тщательное исследование, выявить все возможные риски всех способов проверки подлинности и учесть их при разработке механизмов аутентификации. Также рекомендуется по возможности использовать двухфакторную аутентификацию.

API3:2023 Нарушенная авторизация на уровне свойств объекта

API (особенно REST API) часто предоставляют конечные точки, возвращающие данные обо всех свойствах объекта. Конечная точка API считается уязвимой, если она

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

Для минимизации этого риска необходимо всегда проверять, есть ли у пользователя право на доступ к свойствам объекта, передаваемым через конкретную конечную точку API. Кроме того, следует уменьшить количество возвращаемых данных, насколько позволяет бизнес-логика.

API4:2023 Неограниченное потребление ресурсов

Обработка запросов к API связана с потреблением ресурсов, таких как пропускная способность сети, CPU, память и хранилище данных. В некоторых случаях ресурсы, необходимые для обработки запроса (например, при обращении к базе данных), предоставляются по модели «оплата за запрос» (pay per request).

Часто API не ограничивают клиентские взаимодействия и потребление ресурсов, что может привести к отказу в обслуживании (DoS) или увеличению операционных расходов.

Следовательно, разработчикам необходимо установить ограничения на потребление ресурсов, например, установить лимит потребления памяти, размер передаваемых файлов, количество операций в одном клиентском API-запросе, количество или временной диапазон запросов от одного клиента/пользователя API и так далее.

API5:2023 Нарушенная авторизация на уровне функции

Современные приложения могут включать сложную иерархию пользователей и большое количество ролей и групп, в результате чего разделение между административными и обычными функциями может быть нечетким. При эксплуатации таких уязвимостей злоумышленник может отправлять вызовы к конечной точке API, к которой у него не должно быть доступа, и выполнять критичные действия (создание, обновление, удаление) путем изменения HTTP метода (GET на PUT, например).

Рекомендуется проанализировать конечные точки API на предмет изъянов авторизации на уровне функций. Административные контроллеры и административные функции внутри обычных контроллеров должны выполнять проверку авторизации на основании ролей/групп пользователей. Для доступа к каждой функции должна быть определена конкретная роль.

API6:2023 Неограниченный доступ к конфиденциальным бизнес-потокам

Конечные точки API часто предоставляют доступ к бизнес-потокам, но при разработке конечных точек не всегда учитываются риски, связанные с чрезмерным доступом к тому или иному потоку. Например, воспользовавшись потоком «покупка продукта», злоумышленник может написать скрипт для автоматической покупки, купить весь запас товара, пользующегося высоким спросом, а затем продать его на другой платформе по более высокой цене.

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

API7:2023 Подделка запроса на стороне сервера

Подделка запроса на стороне сервера (SSRF) — это уявимость, при которой API не проверяет URL, предоставленный пользователем. В результате злоумышленники могут заставить серверное приложение отправить запрос на этот URL и получить информацию о внутренней сети (например, открытых портах) или другие критичные данные.

Риск SSRF невозможно полностью устранить, но его можно уменьшить посредством проверки всех данных, отправленных пользователем, отключения переадресации HTTP и создания списка разрешений (принимаемые типы данные, URL-схемы и порты, удаленные источники данных).

API8:2023 Ошибки настроек безопасности

Распространенные ошибки настроек безопасности API включают помимо прочего:

• Недостаточно сильную защиту на любом уровне системы,
• Незакрытые CVE,
• Отсутствие TLS (или устаревшую версию сертификата),
• Отсутствие или неправильную настройку политики разделения ресурсов между источниками,
• Сообщения об ошибках, содержащие стек-трейсы или другую критичную информацию.

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

Для надлежащей защиты API в течение всего жизненного цикла рекомендуется реализовать непрерывный процесс по усилению безопасности, включающий своевременное внедрение патчей, обзор и обновление настроек, автоматический процесс проверки эффективности настроек безопасности.

Это касается всех компонентов и технологий в составе корпоративной ИТ-инфраструктуры.

Ежеквартальные обновления безопасности среды разработки и исполнения Java-приложений Axiom JDK Pro гарантируют отсутствие в рантайме известных уязвимостей и критичных багов.

API9:2023 Ненадлежащее управление активами

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

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

API10:2023 Небезопасное использование API

Разработчики часто не проверяют вводные данные, полученные от сторонних API, особенно если те используются известными компаниями. Однако злоумышленники могут скомпрометировать сторонние API для получения доступа к целевым API, что может привести к утечке данных, инъекциям или DoS.

Для повышения безопасности коммуникации со сторонними API необходимо внедрить проверку всех поступающих данных, обеспечивать соединение по безопасному протоколу (TLS), а также создать перечень ссылок, на которые стороннему API позволено перенаправлять ваш API.

Заключение

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

Java-разработчики могут воспользоваться Axiom JDK Pro — доверенной средой разработки и исполнения Java-приложений с акцентом на безопасность:

• Продукт разрабатывается в соответствии с концепцией жизненного цикла безопасной разработки SDL (Secure Development Lifecycle),
• Все сборки проходят тщательное тестирование перед каждым релизом, включая помимо прочего регрессионные тесты, фаззинг, структурный, динамический и статический анализ,
• Новые версии Axiom JDK Pro включают готовые конфигурации российских TLS-сертификатов, выпущенных Минцифры взамен зарубежных сертификатов,
• Клиенты получают ежеквартальные обновления безопасности в рамках CPU-релизов, экстренные патчи и фиксы, поддержку 24/7 от инженеров команды Axiom JDK и доступ к доверенному репозиторию с проверенными исходными кодами Java-библиотек.

Свяжитесь с нами, чтобы узнать больше об Axiom JDK Pro и других продуктах линейки Axiom JDK для разработки Java-приложений.