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

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

Насколько серьезны угрозы API?

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

Почти все (97%) мировых ИТ-лидеров поэтому теперь согласны, что успешная реализация стратегии API жизненно важна для будущих доходов и роста. Но все чаще сам объем API и их распределение по нескольким архитектурам и командам вызывают беспокойство. В крупном предприятии могут быть десятки или даже сотни тысяч API, ориентированных на клиентов и партнеров. Даже организации среднего размера могут использовать тысячи.

Каково влияние на фирмы?

Угрозы также далеко не теоретические. Только в этом году мы видели:

  • T-Mobile USA признала, что 37 миллионов клиентов имели доступ к своим личным данным и информации об учетной записи через API злоумышленника
  • Неправильно настроенные реализации OAuth (Open Authorization) в Booking.com, которые могли привести к серьезным атакам на захват учетных записей пользователей на сайте

Под угрозой API находятся не только корпоративная репутация и прибыль. Они также могут задерживать важные бизнес-проекты. Более половины (59%) организаций утверждают, что им пришлось замедлить выпуск новых приложений из-за проблем с безопасностью API. Это одна из причин, по которой для половины советов директоров это теперь тема обсуждения на уровне C-уровня.

Топ-три риска API

Существует множество способов, которыми хакеры могут использовать уязвимости API, но OWASP является основным ресурсом для тех, кто хочет понять самые большие угрозы для своей организации. Его список OWASP API Security Top 10 2023 подробно описывает следующие три основных риска безопасности:

  1. Нарушенная авторизация на уровне объектов (BOLA): API не проверяет, должен ли запрашивающий иметь доступ к объекту. Это может привести к краже, изменению или удалению данных. Злоумышленникам достаточно знать о существовании проблемы — для использования BOLA не требуются взломы кода или украденные пароли.
  2. Нарушенная аутентификация: Отсутствие и/или неправильная реализация механизмов защиты аутентификации. OWASP предупреждает, что аутентификация API может быть «сложной и запутанной» для многих разработчиков, у которых могут быть неверные представления о том, как ее реализовать. Сам механизм аутентификации также доступен любому, что делает его привлекательной целью. Конечные точки API, отвечающие за аутентификацию, должны обрабатываться иначе, чем другие, с усиленной защитой. И любой используемый механизм аутентификации должен соответствовать соответствующему вектору атаки.
  3. Нарушенная авторизация на уровне свойств объектов (BOPLA): Злоумышленники могут читать или изменять значения свойств объектов, к которым они не должны иметь доступа. Конечные точки API уязвимы, если они раскрывают свойства объекта, которые считаются конфиденциальными («чрезмерное раскрытие данных»), или если они позволяют пользователю изменять, добавлять/или удалять значения конфиденциальных свойств объекта («массовое назначение»). Несанкционированный доступ может привести к раскрытию данных неуполномоченным сторонам, потере данных или манипулированию данными.

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

Как устранить угрозы API

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

Вот несколько отправных точек:

  • Улучшите управление API, следуя модели разработки приложений, ориентированной на API, которая позволяет вам получить видимость и контроль. Таким образом, вы сдвинете безопасность влево, чтобы применять меры контроля на ранних этапах жизненного цикла разработки программного обеспечения и автоматизировать их в конвейере CI/CD.
  • Используйте инструменты обнаружения API, чтобы устранить количество теневых API, уже существующих в организации, и понять, где находятся API и содержат ли они уязвимости.
  • Разверните API-шлюз, который принимает запросы клиентов и направляет их к нужным серверным службам. Этот инструмент управления поможет вам аутентифицировать, контролировать, отслеживать и защищать трафик API.
  • Добавьте межсетевой экран веб-приложений (WAF) для повышения безопасности вашего шлюза, блокируя вредоносный трафик, включая DDoS-атаки и попытки эксплуатации.
  • Шифруйте все данные (например, через TLS), передаваемые через API, чтобы их нельзя было перехватить при атаках «человек посередине».
  • Используйте OAuth для контроля доступа к API к таким ресурсам, как веб-сайты, без раскрытия учетных данных пользователя.
  • Применяйте ограничение скорости вызовов (rate limiting), чтобы ограничить частоту вызовов вашего API. Это снизит угрозу DDoS-атак и других нежелательных всплесков.
  • Используйте инструмент мониторинга для регистрации всех событий безопасности и маркировки подозрительной активности.
  • Рассмотрите подход нулевого доверия, который предполагает, что ни одному пользователю, активу или ресурсу внутри периметра нельзя доверять. Вместо этого вам потребуется требовать доказательства аутентификации и авторизации для каждой операции.

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

Читать полный анализ на WeLiveSecurity →