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

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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

Примечание.

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

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

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

Несмотря на то, что Управление 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 или пропускной способности для более длительных временных кадров.
  • Оптимизируйте производительность с помощью встроенного кэширования, уменьшив потребление ЦП, памяти и сетевых ресурсов для определенных операций.
  • Применение политик проверки.
  • Для создания API-интерфейсов искусственного интеллекта:
  • Установите минимальное время ответа для серверной службы. Чем дольше серверная служба занимает реагирование, тем больше времени подключение занято в Управление API, поэтому уменьшается количество запросов, которые можно обслуживать в заданном интервале времени.
  • Примените политику CORS для управления веб-сайтами, которым разрешено загружать ресурсы, обслуживаемые через API. Чтобы избежать чрезмерной имитирующей конфигурации, не используйте подстановочные знаки (*) в политике CORS.
  • Хотя Azure имеет защиту на уровне платформы и расширенную защиту от атак типа "отказ в обслуживании" (DDoS), защита приложений (уровня 7) для API может быть улучшена путем развертывания службы защиты ботов перед Управление API — например, Шлюз приложений Azure, Azure Front Door или Azure DDoS Protection. При использовании политики брандмауэра веб-приложения (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 с подстановочными знаками (то есть универсальные API с *  в качестве пути). Убедитесь, что Управление API обслуживает только запросы для явно определенных конечных точек, а запросы к неопределенным конечным точкам отклоняются.
  • Не публикуйте API с открытыми продуктами, для которых не требуется подписка.
  • Если ip-адреса клиентов известны, используйте политику ip-фильтра , чтобы разрешить трафик только из авторизованных IP-адресов.
  • Используйте политику проверки -client-certificate, чтобы применить сертификат, представленный клиентом Управление 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 Серверный запрос forgery

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

  • Если это возможно, не используйте URL-адреса, предоставленные в полезных данных клиента, например в качестве параметров для ВНУТРЕННИх URL-адресов, политики отправки запросов или политики перезаписи URL-адресов .
  • Если Управление API или серверные службы используют URL-адреса, предоставляемые в полезных данных запроса для бизнес-логики, определяют и применяют ограниченный список имен узлов, портов, типов мультимедиа или других атрибутов с политиками в Управление API, например выбор выражений политики и политик.
  • Определите 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 предоставляет более полный и удобный способ проверки маркеров безопасности.
    • Настройте политику CORS и не используйте подстановочный знак * ни для какого параметра конфигурации. Вместо этого явным образом выводите список допустимых значений.
    • Настройте политики проверки в рабочих средах, чтобы проверить схемы JSON и XML, заголовки, параметры запроса и коды состояния, а также обеспечить максимальный размер запроса или ответа.
    • Если Управление API находится за пределами границы сети, проверка IP-адресов клиента по-прежнему возможна с помощью политики ограничения IP-адресов вызывающего объекта. Используйте список разрешений, а не список блокировок.
    • Если сертификаты клиента используются между вызывающим и Управление API, используйте политику сертификата validate-client-certificate. Убедитесь, что для атрибутов 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 позволяет управлять всеми сертификатами. Это централизованное управление сертификатами и может помочь упростить задачи управления операциями, такие как продление или отзыв сертификата. Используйте управляемое удостоверение для проверки подлинности в хранилищах ключей.
  • При использовании локального шлюза убедитесь, что у вас существует процесс периодического обновления образа до последней версии.
  • Представляйте внутренние службы в качестве внутренних сущностей. Настройте учетные данные авторизации, проверку цепочки сертификатов и проверку имени сертификатов, если применимо.
  • По возможности используйте диспетчер учетных данных или управляемое удостоверение для проверки подлинности в внутренних службах.
  • При использовании портала разработчика:
    • Если вы решили локально разместить портал разработчика, убедитесь, что у вас существует процесс периодического обновления локального портала до последней версии. Обновления для управляемой версии по умолчанию происходят автоматически.
    • Используйте идентификатор Microsoft Entra или Azure Active Directory B2C для регистрации и входа пользователей. Отключите проверку подлинности имени пользователя и пароля по умолчанию — это менее безопасный вариант.
    • Назначьте группы пользователей продуктам для управления видимостью API на портале.
  • Используйте Политику 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-интерфейсы не управляются в Azure Управление API.

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

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

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

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

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

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

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