Почему безопасность API становится следующей большой проблемой

С переходом на REST API риски, связанные с культурой DevOps, возрастают из-за новых векторов атак. Что можно сделать, чтобы противодействовать этому? Чтобы выяснить это, я попросил эксперта поделиться с нами своими мыслями по этому поводу. Дмитрий Сотников — 11-кратный обладатель награды Microsoft MVP (Самый ценный профессионал), курирующий APIsecurity.io, веб-сайт сообщества, посвященный всем вопросам, связанным с безопасностью API. Для тех из нас, кто заботится о безопасности (а кто в настоящее время не заботится о безопасности?), давайте уделим пристальное внимание тому, как Дмитрий расскажет нам о рисках и проблемах безопасности API и о том, как это связано с культурой DevOps.

Безопасность API приобретает большое значение, и отрасль реагирует

Распространение веб-API резко увеличило поверхность атаки, и число атак через API стремительно растет. На самом деле Gartner прогнозирует, что к 2022 году API станут вектором атак №1. Традиционная безопасность веб-приложений не может помочь из-за изменений в технологии и архитектуре. Отрасль реагирует выпуском новых руководств по безопасности API, таких как OWASP API Security Top 10 и решений DevSecOps для безопасности API.

API-интерфейсы повсюду, и злоумышленники это замечают

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

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

В результате, по данным Akamai, 83% всего веб-трафика теперь приходится на трафик API. Этот рост API приводит к соответствующим изменениям в поверхности атаки и модели угроз. По оценкам Gartner, к 2021 году открытые API-интерфейсы будут формировать большую поверхность атаки, чем пользовательские интерфейсы, для 90% веб-приложений.

И это уже происходит. Только в 2019 году мы наблюдали множество громких взломов и уязвимостей API, в том числе в Facebook, Amazon Ring, GitHub, Cisco, Kubernetes, Uber, Verizon, MuleSoft, Tinder, First American, Fortnite и даже в Ватикане. назвать несколько.

Безопасность API — это вызов

Это внезапное изменение застало отрасль врасплох. REST API были разработаны так, чтобы быть очень похожими на обычные вызовы веб-приложений. Они унаследовали тот же подход к вызову GET, POST и других операций через транспорт HTTP (или HTTPS). Таким образом, было неявное предположение, что традиционные инструменты безопасности веб-приложений (такие как брандмауэры веб-приложений и сканеры веб-серверов) также охватывают безопасность API.

Но архитектуры на основе API сильно отличаются:

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

В результате 86% пользователей WAF теперь сообщают о пропущенных атаках WAF.

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

Топ-10 безопасности API-интерфейсов OWASP

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

• API1: сломанная авторизация на уровне объекта
• API2: Сломанная аутентификация
• API3: чрезмерное раскрытие данных
• API4: нехватка ресурсов и ограничение скорости
• API5: отсутствует авторизация на функциональном уровне
• API6: массовое присвоение
• API7: неправильная настройка безопасности
• API8: Инъекция
• API9: Неправильное управление активами
• API10: недостаточное ведение журнала и мониторинг

В прошлом году OWASP API Security Top 10 был запущен как отдельный проект.

Для более глубокого изучения OWASP API Security Top 10 вы можете посмотреть этот вебинар. И загрузите шпаргалку 42Crunch, чтобы получить сводку и рекомендации по исправлению.

DevSecOps и безопасность API

Посмотрим правде в глаза: разработчики уже заняты. Им говорят оставаться гибкими, быстро внедрять инновации и позволять своему бизнесу оставаться впереди конкурентов. Процессы DevOps, CI/CD, облачные технологии и микросервисные технологии (такие как Docker и Kubernetes) дали им возможность вносить постепенные изменения и быстрее внедрять их. Однако эти же технологии сделали системы более сложными и значительно расширили поверхность атаки. Работа с безопасностью как отдельной специализированной задачей, которую необходимо выполнить после выпуска продукта из разработки, оказалась неэффективной и неэффективной. Команды безопасности упускают множество пробелов и замедляют процесс инноваций в компании.

Единственный реальный способ справиться со сложностью и гибкостью безопасности API — это сдвинуть безопасность API влево и автоматизировать ее. «Shift-влево» означает, что безопасность API больше не является просто проблемой безопасности во время выполнения, но также и тем, что разработчики встраивают в свой дизайн и тестирование API. Shift-left и DevSecOps пытаются решить проблему, внедряя дизайн и тестирование безопасности в процесс разработки и конвейер CI/CD. Эти усилия будут успешными или неудачными в зависимости от того, как они будут реализованы:

• Встраивайте средства безопасности в существующие конвейеры и инструменты разработчика, чтобы свести к минимуму время обучения и накладные расходы, а также упростить внедрение.
• Установите общие стандарты безопасности, политики и показатели для безопасности, разработчиков, контроля качества, операций — все должны говорить на одном языке.
• Используйте инструменты безопасности, которые предоставляют предписывающие рекомендации, чтобы разработчики знали, что им нужно исправить и почему. Например, какие сторонние библиотеки нужно обновить и до каких версий, какие базовые образы Docker нужно исправить и как, какие API имеют недостатки в дизайне и реализации и как их исправить.
• Убедитесь, что инструменты дают выходные данные, которые можно использовать для продолжения конвейера DevSecOps или для блокировки изменений разработчика: оценка, которую вы можете использовать для принятия решения (выше или ниже порогового значения), наличие критических недостатков и т. д. Должен быть четкий способ принятия автоматизированных решений.
• Охватите каждую фазу жизненного цикла системы: статическую (код и дизайн), динамическую (поведенческие тесты) и среду выполнения (защита).

Такие компании, как 42Crunch (раскрытие информации: автор этой статьи работает там) предлагают коммерческие инструменты безопасности API, которые можно встроить в ваш конвейер.

Бесплатные инструменты безопасности API

Разработчикам API также доступно несколько бесплатных инструментов безопасности. Инструменты разработчика, такие как Microsoft Visual Studio Code, теперь имеют расширения разработки API, включающие аудит безопасности. (Нажмите здесь для получения дополнительной информации.) Если вы не хотите устанавливать какие-либо инструменты локально, здесь также доступен онлайн-инструмент аудита безопасности API.

Встреча с угрозой

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