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

  • Статья

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

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

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

Примечание.

Помимо рекомендаций в этой статье, вы можете включить Defender для API, возможности Microsoft Defender для облака для аналитики безопасности API, рекомендаций и обнаружения угроз. Дополнительные сведения об использовании Defender для API с Управление API

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

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

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

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

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

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

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

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

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

  • При использовании GraphQL примените авторизацию на уровне объекта с помощью политики проверки запроса GraphQL с использованием элемента authorize.

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

Механизмы проверки подлинности часто реализуются неправильно или отсутствуют, что позволяет злоумышленникам использовать недостатки реализации для доступа к данным.

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

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

Используйте Управление API для проверки подлинности и авторизации пользователей:

  • Проверка подлинности. Управление API поддерживает следующие способы проверки подлинности:

    • Обычная проверки подлинности — учетные данные с именем пользователя и паролем.

    • Ключ подписки — обеспечивает такой же уровень безопасности, что и обычная проверка подлинности, и может быть недостаточным. Если ключ подписки скомпрометирован, злоумышленник может получить неограниченный доступ к системе.

    • Сертификат клиента — более безопасный, чем обычные учетные данные или ключ подписки, но не предоставляет той же гибкости, что и протоколы авторизации на основе маркеров, такие как OAuth 2.0.

  • Авторизация — Управление API поддерживает политику проверки JWT для проверки допустимости входящего маркера доступа OAuth 2.0 JWT на основе сведений, полученных из конечной точки метаданных поставщика удостоверений OAuth. Настройте политику для проверки соответствующих утверждений маркеров, аудитории и срока действия. Дополнительные сведения о защите API с помощью авторизации OAuth 2.0 и идентификатора Microsoft Entra.

Дополнительные рекомендации:

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

  • API должны использовать TLS/SSL (защиту транспорта) для защиты учетных данных или маркеров. Учетные данные и маркеры должны отправляться в заголовках запросов, а не в качестве параметров запроса.

  • На портале разработчика Управление API настройте идентификатор Microsoft Entra илиAzure Active Directory B2C в качестве поставщика удостоверений для повышения безопасности учетной записи. Портал разработчика использует CAPTCHA для защиты от атак методом подбора.

Предоставление излишних данных

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

Злоумышленник может попытаться получить доступ к API напрямую (например, повторив допустимый запрос) или перехватить трафик между сервером и API. Анализ действий API и доступных данных может дать злоумышленнику доступ к конфиденциальным данным, которые не используются внешним приложением.

Дополнительные сведения об этой угрозе: API3:2019 Предоставление излишних данных

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

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

    В Управлении API используйте следующие подходы:

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

    • Версии для критических изменений, например удаление поля из интерфейса.

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

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

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

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

  • При использовании GraphQL реализуйте политику проверки запросов GraphQL для проверки запросов GraphQL, авторизации доступа к определенным путям запросов и ограничения размера ответа.

Отсутствие ограничений на потребляемые ресурсы и запросы

Отсутствие ограничения на количество запросов может привести к краже данных или успешной атаке DDoS на внутренние службы, что приведет к сбою для всех потребителей.

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

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

  • Используйте политики ограничения скорости (краткосрочные) и квот (долгосрочные) для управления допустимым количеством вызовов API или пропускной способностью для каждого потребителя.

  • Укажите строгие определения объектов запроса и их свойства в определении OpenAPI. Например, определите максимальное значение для целых чисел подкачки, maxLength и регулярного выражения для строк. Примените эти схемы с политиками проверки содержимого и проверки параметров в Управлении API.

  • Примените максимальный размер запроса с помощью политики проверки содержимого.

  • Оптимизируйте производительность с помощью встроенного кэширования, уменьшив потребление ЦП, памяти и сетевых ресурсов для определенных операций.

  • Примените проверку подлинности для вызовов API (см. раздел Некорректная проверка подлинности пользователя). Отзывайте доступ для пользователей, превышающих лимиты. Например, деактивируйте ключ подписки, заблокируйте IP-адрес с помощью политики ограничения IP-адресов вызывающих объектов или отклоняйте запросы для определенного утверждения пользователя из маркера JWT.

  • Примените политику CORS для управления веб-сайтами, которым разрешено загружать ресурсы, обслуживаемые через API. Чтобы избежать конфигураций с излишними разрешениями, не используйте подстановочные знаки (*) в политике CORS.

  • Установите минимальное время ответа для серверной службы. Чем дольше серверная служба отвечает, тем дольше подключение в Управлении API занято, поэтому за определенный период можно обслужить меньше запросов.

  • Хотя Управление API может защитить серверные службы от атак DDoS, само оно может быть уязвимо для этих атак. Разверните службу защиты бота перед Управление API (например, Шлюз приложений Azure, Azure Front Door или Azure DDoS Protection), чтобы лучше защитить от атак DDoS. При использовании WAF со Шлюзом приложений Azure или Azure Front Door рекомендуется использовать Microsoft_BotManagerRuleSet_1.0.

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

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

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

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

  • По умолчанию защищайте все конечные точки API в Управлении API с помощью ключей подписки.

  • Определите политику проверки JWT и примените обязательные утверждения маркера. Если для некоторых операций требуется применение более строгих утверждений, определите дополнительные политики validate-jwt только для этих операций.

  • Используйте виртуальную сеть Azure или Приватный канал для скрытия конечных точек API из Интернета. Узнайте об использовании вариантов виртуальной сети с Управлением API.

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

  • Не публикуйте API с открытыми продуктами, для которых не требуется подписка.

Массовое назначение

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

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

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

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

  • Точно определите контракты XML и JSON в схеме API и используйте политики проверки содержимого и проверки параметров для блокировки запросов и ответов с незадокументированными свойствами. Блокировка запросов с незадокументированными свойствами снижает риски атак, а блокировка ответов с незадокументированными свойствами затрудняет реконструирование потенциальных векторов атак.

  • Если внутренний интерфейс нельзя изменить, используйте политики преобразования, чтобы переписать полезные данные запросов и ответов и отделить контракты API от внутренних контрактов. Например, маскируйте или фильтруйте данные или удаляйте ненужные свойства JSON.

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

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

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

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

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

  • Правильно настройте TLS шлюза. Не используйте уязвимые протоколы (например, TLS 1.0, 1.1) или шифры.

  • Настройте API для приема только зашифрованного трафика, например через протоколы HTTPS или WSS.

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

  • Использование политик Управления API Azure:

    • Всегда наследуйте родительские политики с помощью тега <base>.

    • При использовании OAuth 2.0 настройте и протестируйте политику проверки JWT, чтобы убедиться в существовании и допустимости маркера JWT, прежде чем он достигнет серверной части. Автоматически проверяйте срок действия маркера, подпись маркера и издателя. Принудительно применяйте утверждения, аудитории, срок действия маркера и подпись маркера с помощью параметров политики.

    • Настройте политику CORS и не используйте подстановочный знак * ни для какого параметра конфигурации. Вместо этого явным образом выводите список допустимых значений.

    • Установите для политик проверки значение prevent в рабочих средах для проверки схем JSON и XML, заголовков, параметров запросов и кодов состояния, а также для принудительного применения максимального размера запроса или ответа.

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

    • Если между вызывающим объектом и Управлением API применяются сертификаты клиента, используйте политику проверки сертификатов клиента. Убедитесь, что для атрибутов validate-revocation, validate-trust, validate-not-before и validate-not-after задано значение true.

      • Сертификаты клиента (взаимный TLS) также можно применять между Управлением API и серверной частью. Требования к серверной части:

        • Настроенные учетные данные для авторизации.

        • Проверка цепочки сертификатов, если применимо.

        • Проверка имени сертификатов, если применимо.

  • При использовании GraphQL применяйте политику проверки запросов GraphQL. Убедитесь, что задан элемент authorization и атрибуты max-size и max-depth.

  • Не храните секреты в файлах политики или в системе управления версиями. Всегда используйте именованные значения Управления API или извлекайте секреты во время выполнения с помощью пользовательских выражений политики.

    • Именованные значения должны быть интегрированы с Key Vault или зашифрованы в Управлении API с пометкой "секрет". Никогда не храните секреты в именованных значениях в виде обычного текста.

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

  • Используйте интеграцию Key Vault для управления всеми сертификатами — это позволяет централизовать управление сертификатами и упростить такие задачи управления операциями, как продление или отзыв сертификатов.

  • При использовании локального шлюза убедитесь, что у вас существует процесс периодического обновления образа до последней версии.

  • Представляйте внутренние службы в качестве внутренних сущностей. Настройте учетные данные авторизации, проверку цепочки сертификатов и проверку имени сертификатов, если применимо.

  • При использовании портала разработчика:

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

    • Используйте идентификатор Microsoft Entra или Azure Active Directory B2C для регистрации и входа пользователей. Отключите проверку подлинности имени пользователя и пароля по умолчанию — это менее безопасный вариант.

    • Назначьте группы пользователей продуктам для управления видимостью API на портале.

  • Используйте Политику Azure для принудительного применения конфигурации на уровне ресурсов Управления API и разрешений в рамках управления доступом на основе ролей (RBAC) для управления доступом к ресурсам. Предоставьте каждому пользователю минимальные необходимые привилегии.

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

  • Не используйте нерекомендуемые функции.

кода SQL

Любая конечная точка, принимающая пользовательские данные, потенциально уязвима для эксплойтов внедрения. Примеры:

  • Внедрение команд, когда злоумышленник пытается изменить запрос API для выполнения команд в операционной системе, в которой размещен API

  • Внедрение SQL-кода, когда злоумышленник пытается изменить запрос API для выполнения команд и запросов к базе данных, от которой зависит API

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

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

  • Политики современных брандмауэров веб-приложений (WAF) охватывают множество распространенных уязвимостей, связанных с внедрением. Хотя в Управлении API нет встроенного компонента WAF, настоятельно рекомендуется развернуть WAF перед экземпляром Управления API. Например, используйте Шлюз приложений Azure или Azure Front Door.

    Внимание

    Убедитесь, что злоумышленник не сможет обойти шлюз, на котором размещен WAF, и подключиться напрямую к шлюзу Управления API или самому API серверной части. Возможные способы устранения рисков: сетевые списки управления доступом, использующие политику Управления API для ограничения входящего трафика по IP-адресу клиента, удаление общего доступа, если он не требуется, а также проверка подлинности на основе сертификата клиента (также известная как взаимная проверка подлинности TLS, или mTLS).

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

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

Ненадлежащее управление активами

Уязвимости, связанные с ненадлежащим управлением активами:

  • Отсутствие соответствующей документации по API или сведений о владельцах.

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

Дополнительные сведения об этой угрозе: API9:2019 Ненадлежащее управление активами

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

  • Используйте четко определенную спецификацию OpenAPI в качестве источника для импорта REST API. Спецификация позволяет инкапсулировать определение API, включая метаданные самостоятельного документирования.

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

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

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

  • Используйте отдельный экземпляр Управления API для каждой среды (например, среды разработки и тестирования и рабочей среды). Убедитесь, что каждый экземпляр Управления API связан со своими зависимостями в той же среде. Например, в тестовой среде тестовый ресурс Управления API должен подключаться к тестовому ресурсу Azure Key Vault и тестовой версии внутренних служб. Используйте методы автоматизации и подход "инфраструктура как код" в рамках DevOps, чтобы обеспечить согласованность и точность между средами и минимизировать человеческий фактор.

  • Используйте теги, чтобы упорядочивать API и продукты и группировать их для публикации.

  • Публикуйте API для использования через встроенный портал разработчика. Убедитесь, что документация по API актуальна.

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

Недостаточное ведение журнала и мониторинг

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

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

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

Следующие шаги

См. также: