Безопасность API: детальный гайд

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

Из чего состоит безопасность API?

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

• Обнаружение API: Определив внутренние и внешние API, организации могут создать более полную картину своей поверхности атаки. Популярные методы обнаружения API включают кроулинг для поиска файлов спецификаций и API-интерфейсов, интеграцию с инструментами управления API и мониторинг трафика API.
• Тестирование безопасности API: после обнаружения их можно проверить на уязвимости вручную или с помощью автоматизированного сканирования. Хотя ручное тестирование API ранее являлось стандартом, огромное количество API-интерфейсов и параметров способствовали тому, что продвинутые инструменты для динамического тестирования безопасности приложений (DAST) теперь широко применяются для автоматизации большей части проверок.
• Защита API: большинство компаний используют шлюз API для маршрутизации их трафика через единую систему с многочисленными мерами безопасности. Это может включать балансировку нагрузки, ограничение скорости и брандмауэр для веб-приложений (WAF), что обеспечивает фильтрацию трафика API в режиме реального времени.

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

Почему безопасность API важна?

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

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

Существует по крайней мере пять причин, почему безопасность API значима для организаций:

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

В чем разница между безопасностью API и безопасностью приложений?

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

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

Безопасность разных типов API

Большинство организаций обычно используют один из нескольких распространенных типов API: REST, SOAP или GraphQL. Хотя меры безопасности на уровне сети больше зависят от архитектуры приложения, чем от типа API, безопасность различных видов прикладных программных интерфейсов на уровне приложения имеет свои нюансы.

REST API

REST является самым популярным типом API, который используется более чем в 85% организаций, имеющих прикладные программные интерфейсы. REST (REpresentational State Transfer) – это не строгий протокол или формат, а стиль архитектуры. В случае с ним HTTP-методы используются как типы операций, и JSON является наиболее распространенным форматом данных.

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

SOAP API

SOAP (Simple Object Access Protocol) – это более давний и менее распространенный формат веб-API. Он используется и сегодня, например, в бизнес-приложениях. В отличие от свободного стиля REST, запросы SOAP API на основе XML должны строго соответствовать конкретной схеме, что делает их менее удобными для простых операций, в том числе для частых изменений в разработке.

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

GraphQL API

GraphQL – это не столько формат API, сколько специализированный язык запросов и управления данными для доступа к API баз данных. Несмотря на то, что это относительно новичок по сравнению с REST и SOAP, он быстро набирает популярность. Его используют до 30% разработчиков API.

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

Основные типы уязвимостей API

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

• Уязвимости связанных приложений: после обхода или преодоления средств защиты на уровне API злоумышленники могут пытаться эксплуатировать уязвимости приложений с помощью вызовов API, включая распространенные атаки инъекций, такие как SQL-инъекция, инъекция команд и межсайтовый скриптинг (XSS). В контексте API, уязвимость SSRF (server-side request forgery, подделка запросов на стороне сервера) может быть особенно опасной, предоставляя доступ к внутренним системам.

Риски безопасности OWASP Top 10 для API

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

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

Эти риски безопасности API можно сгруппировать в пять широких категорий:

1. Авторизация доступа и аутентификация пользователей
2. Контроль и ограничение доступа
3. Управление инвентаризацией API
4. Неправильные настройки безопасности
5. Неисправленные уязвимости веб-приложений

Тестирование безопасности API с помощью DAST

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

Будучи первым поставщиком DAST, который интегрировал сканирование API в свои продукты, Invicti (ранее Netsparker) продолжает быть лидером по точности, охвату и автоматизации сканирования веб-приложений и API. Платформа Invicti имеет множество функций и возможностей для безопасности прикладных программных интерфейсов, в частности:

• Поддержка дефиниций REST, SOAP, GraphQL и gRPC
• Обнаружение API: как задокументированных, так и неизвестных
• Полностью автоматизированное аутентифицированное сканирование
• Централизованная видимость API-интерфейсов и уязвимостей
• Автоматическое переписывание URL для улучшения тестирования безопасности
• Сотни проверок для безопасного и точного обнаружения уязвимостей

Лучшие практики для безопасности API

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

• Определение стратегии безопасности API. Это должно включать политики и средства обнаружения API, тестирования безопасности, инвентаризации, управления и защиты.
• Для больших API в продакшне следует использовать проверенные решения безопасности для защиты при исполнении. Это должно включать контроль доступа, а также автоматизированную фильтрацию и ограничение трафика.
• Важно внедрять и централизовать управление API. Это помогает разработчикам и командам безопасности отслеживать актуальные API и текущие версии спецификаций.
• Следует привлекать команды инженеров для определения безопасных стандартов написания кода, дизайна и разработки API. Это должно включать архитектуру, паттерны дизайна и средства контроля безопасности.
• Без тестирования никогда не следует полагать, что аутентификация пользователей API будет обработана другой системой. Соблюдение таких принципов нулевого доверия особенно важно в случае многослойных API.
• Необходимо включать API в процессы обнаружения и тестирования веб-активов. Это помогает улучшать безопасность API как часть AppSec, а также интегрировать ее в жизненный цикл разработки программного обеспечения (SDLC).
• Методы безопасного написания кода должны включать проверку и очистку входных данных. Это особенно важно для API, где защита идентификаторов объектов имеет решающее значение для предотвращения уязвимостей, связанных с ними.
• Полезно внедрять тестирование безопасности API в DevOps пайплайны, используя интеграции с инструментами разработки и системами отслеживания ошибок.

Создание непрерывных процессов для безопасности веб-приложений и API

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

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