Поделиться через

Рекомендации по устранению десятки угроз безопасности API OWASP с помощью управления API

ПРИМЕНЯЕТСЯ КО ВСЕМ уровням управления API

Замечание

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

Фонд open Web Application Security (OWASP) работает над улучшением безопасности программного обеспечения с помощью проектов программного обеспечения под руководством сообщества, сотен глав по всему миру, десятков тысяч членов и размещения локальных и глобальных конференций.

Проект безопасности API OWASP посвящен стратегиям и решениям для понимания и устранения уникальных уязвимостей и рисков безопасности API. В этой статье мы обсудим последние рекомендации по устранению основных угроз API, выявленных OWASP в их списке 2023 года с помощью службы "Управление API Azure".

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

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

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

Дополнительные сведения об этой угрозе: API1:2023 Сломанный уровень авторизации на уровне объектов

Рекомендации

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

  • Если текущий уязвимый API не может быть изменен в серверной части, управление API может использоваться в качестве резервного копирования. Рассмотрим пример.

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

    • Реализуйте пользовательскую политику для сопоставления идентификаторов из запроса в серверную часть и из серверной части к клиенту, чтобы внутренние идентификаторы не раскрывались.

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

  • Для сценариев GraphQL примените авторизацию на уровне объекта с помощью политики validate-graphql-request, используя элемент authorize.

Поврежденная проверка подлинности

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

Дополнительные сведения об этой угрозе: API2:2023 Сломанная проверка подлинности

Рекомендации

Авторизация на уровне сломанного свойства объекта

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

Дополнительные сведения об этой угрозе: API3:2023 Сломанный уровень авторизации на уровне свойств объекта

Рекомендации

  • Лучший подход к устранению этой уязвимости заключается в том, чтобы внешние интерфейсы, определенные в серверной части API, тщательно разрабатывались и, в идеале, независимо от сохраняемости данных. Они должны содержать только поля, необходимые потребителям API. API следует часто проверять, устаревшие поля должны быть признаны устаревшими, и затем удалены.
  • В службе управления API используйте редакции для корректного управления некритическими изменениями, например, добавления поля в интерфейс, и версии для реализации критических изменений. Также следует версионировать интерфейсы серверной части, которые обычно имеют другой жизненный цикл, чем интерфейсы API, ориентированные на пользователей.
  • Отделить внешние интерфейсы API от реализации внутренних данных. Избегайте привязки контрактов API непосредственно к контрактам данных в внутренних службах.
  • Если невозможно изменить дизайн интерфейса бэкэнда и чрезмерные данные являются проблемой, используйте политики преобразования управления API для изменения данных в ответе и маскировки или фильтрации данных. Проверка содержимого в службе управления API может использоваться с схемой XML или JSON для блокировки ответов с незадокументированных свойств или неправильных значений. Например, удалите ненужные свойства JSON из текста ответа. Блокировка запросов с незадокументированных свойств устраняет атаки, а блокировка ответов с незадокументированных свойств затрудняет обратную инженерию потенциальных векторов атак. Политика проверки содержимого также поддерживает блокировку ответов, превышающих указанный размер.
  • Используйте политику проверки состояния кода , чтобы блокировать ответы с ошибками, неопределенными в схеме API.
  • Используйте политику проверки заголовков , чтобы блокировать ответы с заголовками, которые не определены в схеме или не соответствуют их определению в схеме. Удалите нежелательные заголовки с помощью политики set-header .
  • Для сценариев GraphQL используйте политику запроса validate-graphql-request , чтобы проверить запросы GraphQL, авторизовать доступ к определенным путям запросов и ограничить размер ответа.

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

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

Дополнительные сведения об этой угрозе: Неограниченное потребление ресурсов API4:2023

Рекомендации

  • Используйте политики ограничения скорости по ключу или ограничения скорости, чтобы применить ограничение в более короткие временные окна. Применение более строгих политик ограничения скорости для конфиденциальных конечных точек, таких как сброс пароля, вход или операции регистрации или конечные точки, использующие значительные ресурсы.
  • Используйте политики квота по ключу или ограничение квоты, чтобы контролировать допустимое количество вызовов API или используемой ширины канала передачи данных в длительных временных интервалах.
  • Оптимизируйте производительность с помощью встроенного кэширования, что снижает потребление ЦП, памяти и сетевых ресурсов для определенных операций.
  • Применение политик проверки.
    • max-size Используйте атрибут в политике проверки содержимого, чтобы обеспечить максимальный размер запросов и ответов.
    • Определите схемы и свойства, такие как длина строки или максимальный размер массива, в спецификации API. Используйте политики проверки содержимого, проверки параметров и заголовков проверки , чтобы применить эти схемы для запросов и ответов.
    • Используйте политику validate-graphql-request для GraphQL API и настройте параметры max-depth и max-size.
    • Настройте оповещения в Azure Monitor для чрезмерного потребления данных пользователями.
  • Для генеративных API искусственного интеллекта:
  • Свести к минимуму время, когда серверная служба будет отвечать. Чем дольше серверная служба задерживается с ответом, тем дольше подключение занято в службе управления API, что уменьшает количество запросов, которые можно обслужить в заданном интервале времени.
  • Примените политику CORS для управления веб-сайтами, которые могут загружать ресурсы, обслуживаемые через API. Чтобы избежать чрезмерной имитирующей конфигурации, не используйте подстановочные знаки (*) в политике CORS.
  • Хотя Azure имеет защиту на уровне платформы и расширенную защиту от атак типа "отказ в обслуживании" (DDoS), защита приложений (уровня 7) для API может быть улучшена путем развертывания службы защиты ботов перед управлением API, например шлюза приложений Azure, Azure Front Door или Защиты от атак DDoS Azure. При использовании политики брандмауэра веб-приложения (WAF) с шлюзом приложений Azure или Azure Front Door рекомендуется использовать Microsoft_BotManagerRuleSet_1.0.

Неработает авторизация на уровне функций

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

Дополнительные сведения об этой угрозе: API5:2023 Нарушенные полномочия на уровне функций

Рекомендации

  • По умолчанию необходимо защитить все точки доступа API в службе управления API с помощью ключей подписки или политики авторизации на уровне всех API. Если применимо, определите другие политики авторизации для определенных API или операций API.
  • Проверьте маркеры OAuth с помощью политик.
    • Используйте политику validate-azure-ad-token для проверки токенов Microsoft Entra. Укажите все необходимые утверждения и, если применимо, укажите авторизованные приложения.
    • Для проверки токенов, не выданных Microsoft Entra, определите политику validate-jwt и примените необходимые утверждения токенов. Если возможно, требуйте время истечения срока действия.
    • По возможности используйте зашифрованные маркеры или список конкретных приложений для доступа.
    • Мониторинг и проверка запросов, отклоненных из-за отсутствия авторизации.
  • Используйте виртуальную сеть Azure или приватный канал для скрытия конечных точек API из Интернета. Дополнительные сведения о параметрах виртуальной сети см. в разделе "Управление API".
  • Не определяйте универсальные операции API (то есть, "catch-all" API с * в качестве пути). Убедитесь, что управление API обслуживает только запросы явно определенных конечных точек, а запросы к неопределенным конечным точкам отклоняются.
  • Не публикуйте API с открытыми продуктами , которые не требуют подписки.
  • Если ip-адреса клиентов известны, используйте политику ip-фильтра , чтобы разрешить трафик только из авторизованных IP-адресов.
  • Используйте политику проверки сертификата клиента, чтобы обеспечить соответствие сертификата, предоставленного клиентом экземпляру управления API, указанным правилам проверки и утверждениям.

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

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

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

Рекомендации

  • Сокращение или блокировка доступа на основе отпечатков пальцев клиента. Например, используйте политику возврата ответа с политикой выбора, чтобы заблокировать трафик из безголовых браузеров на основе заголовка User-Agent или согласованности других заголовков.
  • Используйте политику проверки параметров для принудительного применения заголовков запросов в соответствии со спецификацией API.
  • Используйте политику ip-фильтра , чтобы разрешить запросы только из известных IP-адресов или запретить доступ из определенных IP-адресов.
  • Используйте функции частной сети для ограничения внешнего подключения к внутренним API.
  • Используйте политику ограничения скорости по ключу , чтобы ограничить пики потребления API на основе удостоверения пользователя, IP-адреса или другого значения.
  • Управление интерфейсом API с помощью шлюза приложений Azure или службы защиты от атак DDoS Azure для обнаружения и блокировки трафика бота.

Подделка запросов с сервера

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

Дополнительные сведения об этой угрозе: API7:2023 Подделка серверного запроса

Рекомендации

  • Если это возможно, не используйте URL-адреса, предоставленные в полезных данных клиента, например, в качестве параметров для серверных URL-адресов, политики отправки запросов или политики перезаписи URL-адресов.
  • Если службы управления API или серверной части используют URL-адреса, предоставляемые в полезных данных запроса для бизнес-логики, необходимо задать и применять ограниченный список имен узлов, портов, типов медиа или других атрибутов с помощью политик в управлении API, таких как политика choose и выражения политик.
  • Определите timeout атрибут в политиках пересылки и отправки запросов .
  • Проверка и очистка данных запроса и ответа с помощью политик проверки. При необходимости используйте политику set-body для обработки ответа и предотвращения возврата необработанных данных.
  • Используйте частные сети для ограничения подключения. Например, если API не должен быть общедоступным, ограничьте подключение из Интернета, чтобы уменьшить область атаки.

Неправильные настройки безопасности

Злоумышленники могут попытаться использовать уязвимости неправильной настройки безопасности, такие как:

  • Отсутствие усиления безопасности
  • Ненужные функции
  • Сетевые подключения ненужно открыты к Интернету
  • Использование слабых протоколов или шифров

Дополнительные сведения об этой угрозе: неправильное настройка безопасности API8:2023

Рекомендации

  • Правильно настройте TLS шлюза. Не используйте уязвимые протоколы (например, TLS 1.0, 1.1) или шифры.
  • Настройте API только для приема зашифрованного трафика, например через протоколы HTTPS или WSS. Вы можете выполнить аудит и применить этот параметр с помощью политики Azure.
  • Рассмотрите возможность развертывания службы управления API за частной конечной точкой или подключением к виртуальной сети, развернутой в внутреннем режиме. В внутренних сетях доступ можно контролировать из частной сети (через брандмауэр или группы безопасности сети) и из Интернета (через обратный прокси-сервер).
  • Используйте политики управления API Azure:
    • Всегда наследуйте родительские политики с помощью тега <base> .
    • При использовании OAuth 2.0 настройте и проверьте политику validate-jwt для проверки наличия и действительности токена, прежде чем он достигнет серверной части. Автоматически проверяйте срок действия токена, подпись токена и его издателя. Обеспечивать выполнение утверждений, выбор аудитории, истечение срока действия токенов и подпись токенов с помощью параметров политики. Если вы используете Microsoft Entra, политика validate-azure-ad-token предоставляет более полный и удобный способ проверки токенов безопасности.
    • Настройте политику CORS и не используйте подстановочный знак * для любого параметра конфигурации. Вместо этого явно перечисляйте допустимые значения.
    • Настройте политики проверки в рабочих средах, чтобы проверить схемы JSON и XML, заголовки, параметры запроса и коды состояния, а также обеспечить максимальный размер запроса или ответа.
    • Если API-менеджмент находится за пределами сетевой границы, проверка IP-адресов клиента всё ещё возможна с помощью политики ограничение IP-адресов вызывающего клиента. Убедитесь, что он использует список разрешений, а не список блоков.
    • Если сертификаты клиента используются между вызывающим оператором и управлением API, используйте политику проверки сертификата клиента. Убедитесь, что атрибуты validate-revocation, validate-trust, validate-not-before и validate-not-after все установлены на true.
  • Сертификаты клиента (взаимное TLS) также могут применяться между управлением API и серверной частью. Серверная часть должна:
    • Настройка учетных данных авторизации
    • Проверка цепочки сертификатов, где применимо
    • Проверьте имя сертификата, где применимо
    • В сценариях GraphQL используйте политику validate-graphQL-request. Убедитесь, что элемент authorization и атрибуты max-size и max-depth заданы.
  • Не сохраняйте секреты в файлах политики или в системе контроля версий. Всегда используйте именованные значения управления API или извлекайте секреты во время выполнения с помощью пользовательских выражений политики. Именованные значения должны быть интегрированы с Azure Key Vault или зашифрованы в службе управления API, помечая их "секретом". Никогда не храните секреты в именованных значениях с открытым текстом.
  • Публикация API через продукты, для которых требуются подписки. Не используйте открытые продукты , которые не требуют подписки.
  • Убедитесь, что API-интерфейсы требуют ключи подписки, даже если все продукты настроены на требование ключей подписки. Подробнее
  • Требовать утверждения подписки для всех продуктов и тщательно проверять все запросы на подписку.
  • Интеграция Key Vault позволяет управлять всеми сертификатами. Это централизованное управление сертификатами и может помочь упростить задачи управления операциями, такие как продление или отзыв сертификата. Используйте управляемое удостоверение для проверки подлинности в хранилищах ключей.
  • При использовании самостоятельно управляемого шлюза убедитесь в том, что существует процесс, который периодически обновляет образ до последней версии.
  • Представьте бэкенд-сервисы как бэкенд-сущности. Настройте учетные данные авторизации, проверку цепочки сертификатов и проверку имени сертификата, если применимо.
  • По возможности используйте диспетчер учетных данных или управляемое удостоверение для проверки подлинности в внутренних службах.
  • При использовании портала разработчика:
  • Используйте политику Azure , чтобы применить конфигурацию уровня ресурсов управления API и разрешения управления доступом на основе ролей (RBAC) для управления доступом к ресурсам. Предоставьте каждому пользователю минимальные необходимые привилегии.
  • Используйте процесс DevOps и подход инфраструктуры как кода за пределами среды разработки, чтобы обеспечить согласованность содержимого и конфигурации управления API, а также для минимизации человеческих ошибок.
  • Не используйте устаревшие функции.

Неправильное управление инвентаризацией

Уязвимости, связанные с неправильным управлением активами, включают:

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

Дополнительные сведения об этой угрозе: API9:2023 Неправильное управление инвентаризацией

Рекомендации

  • Используйте четко определенную спецификацию OpenAPI в качестве источника для импорта REST API. Спецификация позволяет инкапсулировать определение API, включая самодокументирующие метаданные.
  • Используйте интерфейсы API с точными путями, схемами данных, заголовками, параметрами запроса и кодами состояния. Избегайте операций с шаблонами. Укажите описания для каждого API и операции, включая контактные данные и сведения о лицензии.
  • Избегайте конечных точек, которые не вносят прямого вклада в достижение бизнес-целей. Они ненужно увеличивают область атаки и делают ее более сложной для развития API.
  • Используйте редакции и версии в службе управления API для управления изменениями API. Разработайте надежную стратегию управления версиями серверной части и придерживайтесь максимального количества поддерживаемых версий API (например, 2 или 3 предыдущие версии). Планируйте быстро отменить и в конечном итоге удалить старые, часто менее безопасные версии API. Убедитесь, что элементы управления безопасностью реализованы во всех доступных версиях API.
  • Отдельные среды (например, разработка, тестирование и производство) с различными службами управления API. Убедитесь, что каждая служба управления API подключается к своим зависимостям в одной среде. Например, в тестовой среде тестовый ресурс управления API должен подключаться к тестовом ресурсу Azure Key Vault и тестовых версиях внутренних служб. Используйте методики автоматизации DevOps и инфраструктуры как кода , чтобы обеспечить согласованность и точность между средами и сократить количество человеческих ошибок.
  • Изолируйте административные разрешения для API и связанных ресурсов с помощью рабочих областей.
  • Используйте теги для упорядочивания API и продуктов и группировать их для публикации.
  • Публикация API для использования с помощью портала разработчика. Убедитесь, что документация по API обновлена.
  • Обнаруживайте незадокументированные или неуправляемые API и предоставляйте их с помощью управления API для улучшения управления.
  • Используйте Центр API Azure для обеспечения комплексной централизованной инвентаризации API, версий и развертываний, даже если API не управляются в службе управления API Azure.

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

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

Дополнительные сведения об этой угрозе: API10:2023 Небезопасное использование API

Рекомендации

  • Рекомендуется использовать управление API для работы в качестве фасада для подчиненных зависимостей, с которыми интегрируются внутренние API.
  • Если подчиненные зависимости выполняются с помощью управления API или если подчиненные зависимости используются с политикой отправки запросов в службе управления API, используйте рекомендации из других разделов этой документации, чтобы обеспечить их безопасное и управляемое потребление, включая:
    • Убедитесь, что безопасный транспорт включен и обеспечьте обязательное применение конфигурации TLS/SSL
    • Если возможно, выполните аутентификацию с помощью диспетчера учетных данных или управляемой идентификации.
    • Управление потреблением с помощью политик ограничения скорости по ключу и квоты по ключу
    • Регистрируйте или блокируйте ответы, не соответствующие спецификации API, с помощью политик проверки содержимого и заголовков
    • Преобразование ответов с помощью политики набора текста, например удаление ненужных или конфиденциальных сведений
    • Настройка времени ожидания и ограничения параллелизма

Связанный контент

Дополнительные сведения: