10 основных угроз API OWASP

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

В этом документе описаны различные подходы, которые можно использовать в Apigee для устранения уязвимостей безопасности, выявленных OWASP. Дополнительные подходы, описанные для Apigee, см. в разделе «10 лучших вариантов устранения уязвимостей в Google Cloud по версии OWASP за 2021 год» .

Введение

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

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

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

Потребительские приложения следует считать ненадежными или «публичными», поскольку вы не контролируете платформу, на которой они работают. Следует исходить из того, что любое публичное приложение может быть скомпрометировано, поэтому ему нельзя доверять в вопросах контроля доступа ( API1 , API5 ), фильтрации данных ответов ( API6 ) или безопасного хранения секретов клиента ( API2 ), таких как ключи API или токены доступа. Некоторые рекомендации вытекают из анализа списка OWASP Top 10 за 2019 год:

  • Определите, какие типы клиентских приложений будут использовать ваши API (SPA, мобильные или браузерные), и разработайте соответствующие схемы аутентификации, авторизации и безопасности.
  • Всегда используйте потоки аутентификации OAuth или OpenID Connect с «публичным клиентом» (настоятельно рекомендуется использовать PKCE ).
  • Продумайте бизнес-логику вашего приложения, сначала определите спецификацию OpenAPI, а затем спроектируйте API-прокси таким образом, чтобы они фильтровали все данные ответов с бэкэнда внутри Apigee. Никогда не полагайтесь на логику кода приложения, расположенного ниже по цепочке, для выполнения этой задачи!
  • Отфильтруйте все запросы данных, содержащие персональные данные конкретного пользователя, чтобы разрешить доступ к данным из вашей серверной части только для пользователя, отправившего запрос.

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

Описание угрозы

Недостаточная проверка авторизации запроса на доступ к объекту позволяет злоумышленнику выполнить несанкционированное действие, повторно используя токен доступа. Эта угроза вызвана неправильной настройкой проверок авторизации. Apigee предоставляет политики VerifyApiKey, OAuth и JSON Web Token (JWT), которые помогают защититься от этой уязвимости, однако крайне важно, чтобы эти политики были правильно настроены для предотвращения этой угрозы.

Для предотвращения этой угрозы важно тесное сотрудничество команд разработчиков приложений и специалистов по безопасности. Авторизация по своей природе является сложной темой, и эффективная детальная авторизация требует глубокого понимания бизнес-логики приложения.

С точки зрения внедрения Apigee, следует учитывать два основных аспекта:

  • целостность токена доступа
  • контроль доступа

Целостность токена доступа

Крайне важно убедиться, что предоставленный клиентом токен не был изменен, используя правильный поток OAuth или OpenID Connect, а также соответствующий механизм проверки учетных данных или подписи. Apigee поддерживает все распространенные потоки OAuth .

В число правил проверки токенов доступа Apigee входят:

Контроль доступа

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

Apigee предоставляет два основных механизма для проверки и обеспечения соблюдения политик авторизации:

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

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

Используйте переменные потока, доступные для политик OAuth или JWT, для оценки запросов доступа с помощью условных операторов потока.

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

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

API2:2019 Не работает аутентификация пользователя

Описание угрозы

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

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

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

Здесь следует учесть несколько важных моментов, которые будут рассмотрены в последующих разделах:

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

Проектирование систем безопасности

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

RFC OpenID Connect и OAuth предоставляют широкий спектр делегированных потоков аутентификации и авторизации, а также информацию об участниках этих потоков. Это сложная тема, и неудивительно, что некорректная аутентификация является одной из главных угроз для API по версии OWASP. Подробное руководство по правильной реализации стандартов идентификации выходит за рамки этого документа, однако Apigee предлагает множество дополнительных ресурсов для лучшего понимания потоков OAuth, таких как эта электронная книга , вебинар и примеры реализации .

Политики аутентификации

К числу политик Apigee, помогающих решать проблемы, связанные с идентификацией и аутентификацией, относятся:

Управление дорожным движением

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

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

Управление

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

Apigee предоставляет ряд функций и инструментов для обеспечения целостности реализации и предотвращения ошибок конфигурации.

Управление доступом на основе ролей (RBAC)

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

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

Общие потоки

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

Рисунок: Общие потоки — это многократно используемые наборы политик и условной логики, позволяющие поддерживать составной шаблон.

Операционная безопасность

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

Apigee Sense

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

С помощью Apigee Sense вы можете защитить свои API от таких типов запросов, как:

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

Расширенные операции API

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

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

Расширенные возможности API Ops дополняют существующий механизм оповещений мониторинга API следующими типами расширенных оповещений:

  • Оповещения об аномалиях . Edge обнаруживает проблемы с трафиком и производительностью, избавляя вас от необходимости определять их самостоятельно. Затем вы можете отправить оповещение об этих аномалиях.
  • Уведомления об истечении срока действия TLS-сертификата . Вызывает уведомление, когда срок действия TLS-сертификата подходит к концу.

API3:2019 Чрезмерное раскрытие данных

Описание угрозы

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

Один из принципов проектирования API в Apigee, основанный на принципе « извне внутрь », — это экономия данных . Работайте со своими UX-дизайнерами и разработчиками, чтобы предоставлять через API только те данные, которые необходимы в пользовательском интерфейсе вашего приложения. Бэкенд-системы не были созданы для публичных моделей использования, поэтому одной из первых задач проектирования API в Apigee является сокращение объема предоставляемых данных до минимума, необходимого для создания отличного API-продукта для ваших клиентов и разработчиков.

Еще один из принципов проектирования Apigee — повторное использование . Помимо вопросов безопасности, использование приложения для фильтрации данных, предоставляемых API, приводит к необходимости переноса этой логики фильтрации на все платформы, для которых разрабатывается приложение.

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

В следующих разделах рассматривается, как:

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

Переписывание ответов и запросов

Как правило, бэкэнд-системы не предназначены для использования в общедоступных приложениях или в ненадежных общедоступных сетях. Apigee Edge разработан для того, чтобы позволить вам развертывать общедоступные API-продукты, защищая ваши бэкэнды от чрезмерного раскрытия данных.

Для этого Apigee использует три ключевых принципа:

  • Назначить сообщение
  • Выноски кода
  • Обработка ошибок

Назначить политику сообщений

Политика «Назначить сообщение» изменяет или создает новые сообщения запроса и ответа в процессе работы API-прокси. Эта политика позволяет выполнять следующие действия с этими сообщениями:

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

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

Сложная переработка кода с использованием собственных разработок.

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

С помощью процедурного кода вы можете:

  • Создавайте или изменяйте сложные значения в теле запроса, такие как значения запроса и ответа.
  • Перезаписывать URL-адреса, например, для маскировки URL-адреса целевой конечной точки.

Apigee Edge включает в себя отдельные политики для поддерживаемых языков: политику JavaScript , политику вызовов Java и политику сценариев Python .

Обработка ошибок

Apigee позволяет выполнять пользовательскую обработку исключений с помощью политики типа Raise Fault . Политика Raise Fault, являющаяся разновидностью политики Assign Message, позволяет генерировать пользовательский ответ об ошибке в случае возникновения ошибки.

Общие потоки

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

API4:2019 Нехватка ресурсов и ограничение скорости запросов

Описание угрозы

Не внедряя политики ограничения скорости запросов, злоумышленники могут перегрузить серверную часть, осуществляя атаки типа «отказ в обслуживании».

Эту угрозу можно легко устранить, используя следующие функции Apigee:

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

Ограничение скорости с помощью квот и политики блокировки пиковых нагрузок.

Apigee предлагает два способа ограничения скорости запросов:

  • Функция Spike arrest предоставляет общую политику, определяемую на уровне API-прокси, для ограничения общего количества входящих запросов к бэкэнду.
  • Квоты предоставляют детальный инструмент для обеспечения соблюдения правил квотирования, как на уровне API-прокси, так и на уровне API-продукта.

Арест Спайка

Политика защиты от всплесков трафика (Spike Arrest) предотвращает резкие скачки трафика. Эта политика ограничивает количество запросов, обрабатываемых API-прокси и отправляемых на бэкэнд, защищая от задержек в работе и простоев, используя скользящее среднее значение, определяемое в рамках политики.

Квоты

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

  • Продукт, содержащий API-прокси.
  • Приложение запрашивает API.
  • Разработчик приложения
  • Многие другие критерии

Данная методика более детализирована, чем методика задержания Spike, и, как правило, должна применяться одновременно с ней.

Обнаружение ботов с помощью Apigee Sense

С помощью Apigee Sense вы можете явно разрешать, блокировать или помечать запросы от определенных клиентов, диапазонов IP-адресов или организаций автономных систем на основе того, что эти клиенты или местоположения демонстрируют вредоносное или подозрительное поведение. Apigee Edge применяет эти действия к запросам до того, как ваши API-прокси обработают их. Например, диапазон IP-адресов или конкретный клиент, демонстрирующий поведение типа «грубый угадыватель», может быть обнаружен, а затем заблокирован или помечен.

Обнаружение угроз с помощью расширенного мониторинга операций API.

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

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

Описание угрозы

Эта угроза является разновидностью API1 и также представляет собой уязвимость авторизации. С помощью этой угрозы злоумышленник может выполнять действия, отправляя запросы к функциям, к которым у него нет доступа. Например, злоумышленник может изменять или удалять данные, к которым он имеет доступ только для чтения, если конечная точка API не проверяет глагол HTTP-запроса, заменяя GET на PUT или DELETE. Или, не обеспечив достаточно строгого контроля доступа к пути URI ресурса API, конечная точка API может позволить злоумышленнику просматривать данные другого пользователя, просто изменив путь в запросе.

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

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

  • Что именно защищается? Продумайте стратегию развития вашего API-продукта и внедрите логическую сегментацию функциональности, используя лучшие практики RESTful для проектирования путей и ресурсов, предоставляемых прокси-серверами API Apigee, продуктами и функциями приложений.
  • Кто получает доступ к ресурсам вашего API? Определите основные категории пользователей и внедрите систему доступа по умолчанию с «минимальными привилегиями», используя некоторые функции аутентификации и авторизации Apigee, описанные в API1 и API2 .
  • Как обеспечивается соблюдение ваших политик доступа? Используйте условные потоки и ошибки для проверки пути URL и глагола всех запросов API.

Рисунок: На этой диаграмме показано, как в Apigee будет обеспечиваться авторизация на уровне функций с использованием областей действия, предоставленных в токене доступа в качестве прав доступа.

Логическая сегментация с использованием API-прокси, продуктов и приложений.

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

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

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

Контроль доступа на уровне функций с использованием областей действия OAuth и утверждений JWT.

Хотя рассмотренные выше подходы к авторизации для API1:2019 «Авторизация неработающих объектов» обеспечивают детальный контроль доступа на уровне объектов, не менее важно учитывать и более детальный контроль доступа на уровне функций. Разрешен ли вообще запрашивающему пользователю запрашивать этот URL-адрес? Такая политика часто определяется для каждой пользовательской персоны (клиент, сотрудник, администратор, внутренний или сторонний разработчик).

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

Проверка запросов с использованием условных потоков

На базовом уровне вызов REST API состоит из следующих элементов:

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

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

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

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

API6:2019 Массовое задание

Описание угрозы

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

Эта угроза возникает, когда нефильтрованные данные (обычно в формате JSON или XML) отправляются клиенту, что позволяет злоумышленнику угадать детали реализации ваших бэкэнд-систем, а также имена свойств конфиденциальных элементов данных. Результатом такой атаки может стать возможность чтения или манипулирования недопустимыми данными, или, в худшем случае, уязвимость для удаленного выполнения кода.

Как правило, в создании подобных угроз участвуют два фактора:

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

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

Политика фильтрации спецификаций OpenAPI

Политика OASValidation ( проверка спецификации OpenAPI ) позволяет проверять входящие запросы или ответы на соответствие спецификации OpenAPI 3.0 (JSON или YAML). Эта политика позволяет:

  1. Разработайте свой API, создав спецификацию OpenAPI (OAS).
  2. Реализуйте необходимую логику посредничества, безопасности и кэширования для безопасного предоставления доступа к API-продукту из вашего бэкэнда с помощью Apigee.
  3. Проверяйте входящие запросы на соответствие схеме данных, определенной в вашей спецификации OAS, включая базовый путь , глагол , политику сообщений запроса и параметры.

Политика проверки SOAP-сообщений

Политика проверки SOAP-сообщений позволяет проверять запросы на основе XML, либо проверяя XML-сообщение на соответствие схеме XSD, либо проверяя SOAP-сообщение на соответствие определению WSDL. Кроме того, вы можете использовать политику проверки сообщений для подтверждения корректности полезной нагрузки JSON или XML-сообщения, что включает проверку следующих параметров в XML или JSON-сообщении:

  • Имеется единственный корневой элемент.
  • В контенте отсутствуют недопустимые символы.
  • Объекты и теги правильно вложены друг в друга.
  • Начальный и конечный теги совпадают.

API7:2019 Неправильная настройка безопасности

Описание угрозы

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

  • Неправильно настроенный TLS
  • Сообщения об ошибках с трассировкой стека.
  • Необновленные системы
  • Открытые панели управления хранилищем или сервером.

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

  1. Разработка и стандартизация процессов упрочнения и ремонта.
  2. Разработка системы управления экосистемой API.
  3. Ограничение административного доступа и включение аудита и оповещений.

Совместные потоки и точки подключения потоков

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

Мониторинг API

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

Рисунок: Apigee API Monitoring предоставляет широкий спектр инструментов для мониторинга, исследования и реагирования на проблемы. Он использует лучшие в своем классе интеллектуальные функции платформы Google Cloud Platform.

Apigee Sense

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

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

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

Инъекция API8:2019

Описание угрозы

Untrusted injection of data, such as SQL, NoSQL, XML Parsers, ORM, LDAP, OS Commands, and JavaScript, into API requests can result in the execution of unintended commands or unauthorized data access. Attackers will feed the API with malicious data through whatever injection vectors are available such as direct input, parameters, integrated services, and so on, expecting it to be sent to an interpreter. Attackers can discover these flaws easily when reviewing the source code using vulnerability scanners and fuzzers. A successful injection can lead to information disclosure impacting the confidentiality and data loss or in some cases it may also lead to DoS.

Best practices to mitigate injection errors/attacks include strictly defining the input data such as schemas, types, string patterns, performing input validation, limit checks and enforcing them at runtime. The Apigee platform allows validating the incoming data using filters to only allow valid values for each input parameter.

Apigee Edge, acting as a server for the incoming API requests, checks to ensure that the payload structure falls within an acceptable range, also known as a limit check. You can configure an API proxy so that the input validation routine transforms the input to remove risky character sequences and replace them with safe values.

Regular Expression Protection policy

The RegularExpressionProtection policy extracts information from a message (for example, URI Path, Query Param, Header, Form Param, Variable, XML Payload, or JSON Payload) and evaluates that content against predefined regular expressions. If any specified regular expressions evaluate to true, the message is considered a threat and is rejected. A regular expression, or regex for short, is a set of strings that specify a pattern in a string. Regular expressions enable content to be programmatically evaluated for patterns. Regular expressions can be used, for example, to evaluate an email address to ensure that it is properly structured.

The most common usage of RegularExpressionProtection is the evaluation of JSON and XML payloads for malicious content.

No regular expression can eliminate all content-based attacks, and multiple mechanisms should be combined to enable defense-in-depth. This section describes some recommended patterns for preventing access to content.

There are several other approaches to validating input available with the Apigee platform:

Validate Content Types

Content type refers to content of a file which is transferred via HTTP and classified according to a two-part structure. Apigee recommends to validate the content types for the Request and Response using conditional logic as explained below.

API9:2019 Improper assets management

Описание угрозы

Insufficient environment management and environment segregation allows attackers to access under-secured API endpoints. Lack of governance safeguards also cause unnecessary exposure of deprecated resources.

This threat can be addressed by leveraging Apigee's matured capabilities to manage the full API life cycle, allowing you to create a comprehensive governance model that enables collaboration among teams, and at the same time, apply separation of responsibilities between security stakeholders and API developers. Boundaries and controls can be configured and maintained using:

Organizations, Environments, and Revisions : Virtual and physical guardrails that guarantee isolation and a secured promotion process through runtime contexts.

Role Based Access Control : Only the necessary people on your API teams will have permissions to manage configuration changes and also the promotion process.

Audience Management for API Documentation : Once an API has been published in the developer portal, you can limit the visibility of documentation by managing target audiences.

Flow Hooks : You can enforce global policies and patterns that can be managed as privileged guardrails that cannot be modified by API developers.

Organizations and Environments

Configuration artifacts, users, and features in Apigee can be scoped to specific organizations and/or environments. This means that the platform has pre-built guardrails that can be placed around APIs and their supporting configuration.

Organizations : An organization is the top-level tenant in Apigee. It enables you to have full segregation for traffic, configuration, and users. As a governance best practice, you should consider having separate production and non-production organizations. This practice effectively avoids mixing production data, users, and traffic with lower environments.

Environments : APIs in Apigee can be promoted through multiple deployment states; each state is linked to an execution context. The environment context is not carried along during the promotion process, therefore avoiding exposing sensitive configuration to unprivileged users.

Revisions : Revisions allow APIs and individual features to be promoted seamlessly through environments.

Управление доступом на основе ролей

In order to mitigate API9 it is imperative to have clear definitions of and separation of duties between security stakeholders and API Developers. As previously stated in this document, Apigee has flexible Role Based Access Control capabilities that allow you to assign permissions to custom roles. For this specific threat, roles can be scoped to have limited privileges per organization, environments, or more granular configuration permissions. As a preferred practice, consider limiting privileges to change the deployment state of APIs through environments and also to make sure developers are unable to access or modify global security libraries (Flow Hooks). These limited roles will prevent unsolicited changes to global security policies that have broad coverage on both legacy and current published endpoints.

Audience Management for API Documentation

A Developer Portal is a pivotal component for the success of your API Strategy; it allows you to keep a comprehensive inventory of all documentation related to your APIs including hosts/endpoints, resources, operations, payload schemas, and more. In Apigee you can group your APIs using API Product constructs. API Products are defined by bundles of resources and operations that fall within the same business and security context (eg service plan, business domain, category, company hierarchy, etc.).

With Apigee's Integrated Developer Portal you can publish API Products and restrict the visibility of published content by managing target audiences. This capability complies with a content segmentation strategy that aligns with business and security requirements.

Flow Hooks

The promotion and release processes for APIs must always include security compliance and certification processes. To be effective, API teams using the appropriate tools should be able to create guardrails that guarantee the separation of responsibilities and while maintaining agile release cycles.

Apigee allows you to elevate security governance duties by enforcing global policies through Flow Hooks . These global policies can be managed as privileged guardrails that cannot be modified by API developers, therefore guaranteeing separation of responsibilities and also promoting agility by applying default security and, by extension, providing security compliance for all APIs deployed in a given execution environment.

Figure: Privileged guardrails can be configured in Apigee through Flow Hooks and Shared Flows. Security stakeholders are responsible for maintaining security related global policies. These features guarantee separation of responsibilities and promote agile development life cycles.

API10:2019 Insufficient logging & monitoring

Описание угрозы

Insufficient logging, monitoring, and alerts allows attacks in progress to go undetected and therefore a strategy should be required to obtain insights over critical events that have impact over your business.

Event and logging management strategies for APIs should consider the following best practices:

  • Logs Management Policy : Document and enforce rules to standardize and control logs verbosity, log levels, log integrity, centralized repository, and more
  • Event Management Policy : Guarantee that every event should be traceable to its source. Also, events should be able to be categorized by criticality and business impact
  • Reports and Audits : Security and operations stakeholders should be able to access and react to logs and events in real time. Additionally, reinforcement cycles can be performed by stakeholders to adjust detection patterns based on historical data

Apigee provides the necessary tools to create a comprehensive event and logging management strategy. These tools include:

Message Logging Policy : Create log streams based on traffic data or metadata from your API traffic. You have the flexibility to decide stream verbosity by leveraging conditional logic and message templates .

Google's Cloud Operation Suite : Leverage the out of box integration into highly scalable monitoring and logging tools from Google.

Service Callout Policy : Adds support for logs streams that require HTTP endpoints to send events.

Analytics : Access and analyze historical traffic metadata through out of box and/or customized reports. Create and manage alerts based on trends and understand traffic anomalies.

API Monitoring : As previously described, this tool provides alerting capabilities that can be triggered based on critical events. Traffic logs can be further analyzed and acted upon.