10 угроз для открытой экосистемы API

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

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

Однако открытые API также сопряжены с рисками и проблемами, и предприятиям необходимо решить эти проблемы, прежде чем вступать на этот путь.

В этой статье мы расскажем о 10 угрозах экосистемы открытых API для ИТ-инженеров, руководителей и специалистов по кибербезопасности. Мы также представим Gravitee, современную платформу управления API, которая поставляется с необходимыми инструментами и технологиями для решения проблем разработки, развертывания и обслуживания API.

Экономика API: Возможность и угроза

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

Однако по своей природе открытые API также привлекают внимание как индивидуальных, так и организованных киберпреступников. Поскольку API являются транзакционными, они также уязвимы для случайного или злонамеренного раскрытия личной, финансовой и другой конфиденциальной информации. Незащищенные конечные точки или непроверенные запросы клиентов могут подвергнуть API таким атакам, как DDoS, SQL-инъекции или ransomware. Это может серьезно повлиять как на разработчиков, так и на потребителей открытых API.

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

10 угроз для открытых API (или любых API)

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

1. Атаки на уровне объектов

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

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

2. Эксплойты аутентификации пользователя

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

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

3. Неосторожное раскрытие данных

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

4. Распределенный отказ в обслуживании (DDoS)

Без ограничения скорости доступа к запросам конечная точка API уязвима для распределенных атак типа «отказ в обслуживании» (DDoS). В ходе таких атак злоумышленники запускают множество запросов к конечной точке API из нескольких источников (часто взломанных систем), перегружают конечную точку и выводят ее из сети. Популярные открытые API могут быть обычными объектами таких атак.

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

5. Взломы авторизации

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

6. Слабые места массового назначения

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

7. Недостатки неправильной конфигурации системы безопасности

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

8. Уязвимости, связанные с внедрением кода

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

9. Плохое управление активами

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

10. Неадекватное протоколирование и мониторинг

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

Устранение угроз, связанных с открытыми API

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

• Мониторинг цепочки поставок программного обеспечения и анализ состава программного обеспечения позволяет выявить уязвимые компоненты, такие как небезопасные библиотеки сторонних разработчиков.
• Статическое тестирование безопасности приложений (SAST) проверяет код приложения и может выявить уязвимости.
• Динамическое тестирование безопасности приложений (DAST) моделирует атаки на код приложения во время его работы и таким образом находит возможные слабые места.
• Решения по управлению инцидентами и событиями безопасности (SIEM) могут сканировать журналы приложений, чтобы найти возможные нарушения, подозрительные действия, тенденции или аномалии.
• Решения Security Orchestration, Automation, and Response (SOAR) идут дальше, выполняя шаги по устранению последствий из рабочих программ при обнаружении аномалий или угроз безопасности.
• Надежный механизм аутентификации позволяет проверять пользователей API. Аналогично, надежный механизм авторизации позволяет пользователям выполнять только те действия, которые им разрешены.
• Шифрование данных с помощью симметричных ключей и защита конечных точек API с помощью сертификатов SSL/TLS обеспечивают защиту данных в состоянии покоя и при передаче.
• Надежный план аварийного восстановления, прошедший тестирование, гарантирует быстрое восстановление и возвращение API в рабочее состояние, даже если он был скомпрометирован.

Кроме того, шлюз API может значительно повысить безопасность и стабильность API, предоставляя услуги обнаружения сервисов, маршрутизации, балансировки нагрузки, высокой доступности и наблюдаемости для API, размещенных на его базе. Он позволяет легко защитить все каналы связи с помощью SSL/TLS, реализовать ограничение скорости для предотвращения DDoS-атак, а также ограничить полезную нагрузку клиентских запросов и размер ответов API. API-шлюзы также можно использовать с брандмауэром веб-приложений (WAF) для обеспечения дополнительного уровня безопасности.

Заключение

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

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

Чтобы узнать больше о Gravitee, закажите демонстрацию.