10 главных угроз веб-приложений OWASP

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

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

Обзор

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

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

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

  • URL-адрес
  • Заголовки
  • Путь
  • Полезная нагрузка

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

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

Решения Apigee вошли в десятку лучших по версии OWASP 2017 года

Когда дело доходит до создания и защиты веб-приложений, возникает множество проблем с безопасностью. OWASP опубликовала список 10 главных угроз безопасности веб-приложений OWASP за 2017 год . Хотя веб-приложение состоит из множества частей, большинство современных веб-приложений в значительной степени полагаются на REST API. Apigee не предназначен для удовлетворения всех потребностей веб-приложения в области безопасности, но может сыграть решающую роль в обеспечении безопасности REST API. Ниже приведены основные угрозы безопасности OWASP с описанием того, как вы можете использовать Apigee для устранения этих угроз.

А1:2017 - Инъекция

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

Существует несколько подходов к проверке ввода с помощью платформы Apigee:

  • JSONThreatProtection проверяет полезную нагрузку JSON на наличие угроз.
  • XMLThreatProtection проверяет полезную нагрузку XML на наличие угроз.
  • Проверка параметров может быть выполнена с помощью JavaScript .
  • Проверка заголовка может выполняться с помощью JavaScript .
  • SQLCodeInjection можно обрабатывать с помощью политики RegularExpressionProtection .

Проверьте типы контента:

A2:2017 – Нарушение аутентификации и управления сеансами

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

Проверка ключа API

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

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

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

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

Apigee также поддерживает возможность импорта существующих ключей API из внешних источников.

Для типов предоставления OAuth используются как идентификатор клиента, так и секрет.

ОАутентификация 2.0

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

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

JWT

Веб-токены JSON, или JWT, обычно используются для обмена утверждениями или утверждениями между подключенными приложениями. Apigee обеспечивает поддержку JWT, используя три политики.

  • Генерировать токены JWT (поддерживает подпись HS256 и RS256)
  • Проверка токенов JWT
  • Декодировать токены JWT без проверки

A3:2017 – Раскрытие конфиденциальных данных

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

TLS (Transport Layer Security, предшественником которого является SSL) — это стандартная технология безопасности для установления зашифрованной связи между веб-сервером и веб-клиентом, например браузером или приложением. Apigee поддерживает как односторонний, так и двусторонний TLS.

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

Southbound TLS (apigee как клиент, подключающийся к серверной службе) поддерживается за счет использования конфигурации целевого сервера . Целевой сервер можно настроить для одностороннего или двустороннего TLS.

Apigee поддерживает множество вариантов конфигурации TLS.

Двустороннее применение TLS гарантирует, что клиент использует сертификат, который уже подключен к Apigee. OWASP также предоставляет лучшие практики TLS .

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

Ниже приведены рекомендации по защите конфиденциальных данных:

  • Используйте платформу, поддерживающую односторонний и двусторонний TLS, которая будет обеспечивать защиту на уровне протокола.
  • Используйте такие политики, как политика AssignMessage и политика JavaScript, чтобы удалять конфиденциальные данные перед их возвратом клиенту.
  • Используйте стандартные методы OAuth и рассмотрите возможность добавления HMAC, хэша, состояния, nonce, PKCE или других методов для повышения уровня аутентификации для каждого запроса.
  • Используйте настройки маскировки данных , чтобы замаскировать конфиденциальные данные в инструменте Edge Trace.
  • Будьте осторожны при хранении конфиденциальных данных в кеше (или шифруйте конфиденциальные данные, хранящиеся в кеше). В Edge вы можете зашифровать хранящиеся конфиденциальные данные в картах значений ключей .

A4:2017 – Внешние объекты XML

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

Политика Apigee ExtractVariables позволяет извлекать содержимое из запроса или ответа и назначать это содержимое переменной. Вы можете извлечь любую часть сообщения, включая заголовки, пути URI, полезные данные JSON/XML, параметры формы и параметры запроса. Политика работает путем применения текстового шаблона к содержимому сообщения и, при обнаружении совпадения, установки переменной с указанным содержимым сообщения.

Apigee имеет встроенный анализатор XML как часть платформы, которая использует XPath для извлечения данных. Он также имеет политику XMLThreatProtection для защиты от вредоносных полезных данных XML.

A5:2017 - Нарушен контроль доступа

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

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

Элементы управления доступом для пользовательского интерфейса Edge

Контроль доступа для портала разработчиков Apigee

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

Контроль доступа для доступа к API среды выполнения Apigee

  • Доступ к API можно обеспечить с помощью ключей API, токенов OAuth, областей OAuth, сертификатов и других методов.
  • Поставщик API настраивает доступные ресурсы, определяя продукт API . Доступ предоставляется либо вручную в пользовательском интерфейсе, через API управления, либо через портал разработчика. Когда приложению разработчика предоставляется доступ к продукту API, оно получает идентификатор клиента и секретный код, которые используются в процессе аутентификации.
  • Apigee может интегрироваться с любым поставщиком удостоверений для выполнения OAuth.
  • Apigee может генерировать токены JWT или использовать другие методы для отправки идентификационных данных пользователя целевым службам. Целевые службы могут использовать это удостоверение для ограничения доступа к службам и данным по мере необходимости.

A6:2017-Неправильная конфигурация безопасности

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

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

Релизы продуктов Apigee обеспечивают защиту от библиотек с уязвимостями. Apigee может выпустить дополнительные исправления или обновления, если будут обнаружены новые уязвимости. Публичное облако Edge обновляется автоматически. Клиенты Edge для частного облака (локально) должны самостоятельно устанавливать исправления для продукта.

A7:2017-Межсайтовый скриптинг (XSS)

Межсайтовый скриптинг (XSS) позволяет злоумышленникам выполнять скрипты в веб-браузерах пользователей для управления пользовательскими сеансами, манипулирования веб-сайтами или других способов злонамеренного воздействия на пользователей. Проблемы XSS не обязательно связаны с API, но Apigee предоставляет политики защиты от угроз, которые можно использовать для защиты от XSS в API. Используя регулярные выражения с помощью политики RegularExpressionProtection или политики JavaScript , проверьте полезные данные и значения параметров на наличие JavaScript и других атак типа внедрения.

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

A8:2017 — Небезопасная десериализация

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

Apigee не рекомендует десериализацию. Однако политика JSONThreatProtection и политика RegularExpressionProtection могут помочь защититься от вредоносных полезных данных JSON. Политику JavaScript также можно использовать для сканирования полезных данных на наличие вредоносного содержимого. Кэш и другие политики могут использоваться для защиты от атак повторного воспроизведения. На уровне инфраструктуры платформа Apigee также имеет встроенные средства защиты запущенных процессов.

A9:2017 - Использование компонентов с известными уязвимостями

Поскольку платформы, библиотеки и модули работают с полным выполнением и доступом CRUD, злоумышленники могут использовать уязвимости компонентов для атаки на системы.

Регулярные выпуски продуктов Apigee обеспечивают защиту от уязвимостей компонентов, особенно при обнаружении конкретных уязвимостей. Публичное облако Apigee обновляется автоматически, и Apigee уведомляет клиентов Edge for Private Cloud, когда локальные исправления доступны для установки.

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

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

Apigee имеет несколько способов ведения журнала, мониторинга, обработки ошибок и ведения журнала аудита.

Ведение журнала

  • Сообщения журнала можно отправлять в Splunk или другую конечную точку системного журнала с помощью политики MessageLogging .
  • Данные аналитики API можно получать через API аналитики , а также импортировать или экспортировать в другие системы.
  • В Edge для частного облака вы можете использовать политику MessageLogging для записи в локальные файлы журналов. Также доступны файлы журналов каждого из работающих компонентов.
  • Политику JavaScript можно использовать для отправки сообщений журнала в конечную точку ведения журнала REST синхронно или асинхронно.

Мониторинг

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

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

Журналы аудита

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

Решения Apigee для устранения уязвимостей OWASP 2013 г.

Когда OWASP обновил свой список за 2017 год, некоторые уязвимости из списка 2013 года были исключены. Они по-прежнему представляют собой реальную угрозу. В следующих разделах описывается, как бороться с этими угрозами с помощью Apigee.

A8:2013 — Подделка межсайтового запроса (CSRF)

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

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

  • Это скорее проблема браузера, а не проблема продукта API. Вы можете устранить эту уязвимость с помощью OpenID Connect, OAuth и других методов.
  • Рассмотрите возможность использования методов HMAC, состояния, хэша, nonce или PKCE для предотвращения атак подделки и повторного воспроизведения.

A10:2013 – Непроверенные редиректы и переадресации

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

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

  • Используйте OAuth и выполняйте проверку при каждом запросе.
  • Предотвратите неожиданные 302-перенаправления, проверяя коды ответов в логике прокси-сервера API и соответствующим образом обрабатывая перенаправления.
,

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

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

Обзор

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

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

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

  • URL-адрес
  • Заголовки
  • Путь
  • Полезная нагрузка

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

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

Решения Apigee вошли в десятку лучших по версии OWASP 2017 года

Когда дело доходит до создания и защиты веб-приложений, возникает множество проблем с безопасностью. OWASP опубликовала список 10 главных угроз безопасности веб-приложений OWASP за 2017 год . Хотя веб-приложение состоит из множества частей, большинство современных веб-приложений в значительной степени полагаются на REST API. Apigee не предназначен для удовлетворения всех потребностей веб-приложения в области безопасности, но может сыграть решающую роль в обеспечении безопасности REST API. Ниже приведены основные угрозы безопасности OWASP с описанием того, как вы можете использовать Apigee для устранения этих угроз.

А1:2017 - Инъекция

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

Существует несколько подходов к проверке ввода с помощью платформы Apigee:

  • JSONThreatProtection проверяет полезную нагрузку JSON на наличие угроз.
  • XMLThreatProtection проверяет полезную нагрузку XML на наличие угроз.
  • Проверка параметров может быть выполнена с помощью JavaScript .
  • Проверка заголовка может выполняться с помощью JavaScript .
  • SQLCodeInjection можно обрабатывать с помощью политики RegularExpressionProtection .

Проверьте типы контента:

A2:2017 – Нарушение аутентификации и управления сеансами

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

Проверка ключа API

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

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

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

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

Apigee также поддерживает возможность импорта существующих ключей API из внешних источников.

Для типов предоставления OAuth используются как идентификатор клиента, так и секрет.

ОАутентификация 2.0

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

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

JWT

Веб-токены JSON, или JWT, обычно используются для обмена утверждениями или утверждениями между подключенными приложениями. Apigee обеспечивает поддержку JWT, используя три политики.

  • Генерировать токены JWT (поддерживает подпись HS256 и RS256)
  • Проверка токенов JWT
  • Декодировать токены JWT без проверки

A3:2017 – Раскрытие конфиденциальных данных

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

TLS (Transport Layer Security, предшественником которого является SSL) — это стандартная технология безопасности для установления зашифрованной связи между веб-сервером и веб-клиентом, например браузером или приложением. Apigee поддерживает как односторонний, так и двусторонний TLS.

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

Southbound TLS (apigee как клиент, подключающийся к серверной службе) поддерживается за счет использования конфигурации целевого сервера . Целевой сервер можно настроить для одностороннего или двустороннего TLS.

Apigee поддерживает множество вариантов конфигурации TLS.

Двустороннее применение TLS гарантирует, что клиент использует сертификат, который уже подключен к Apigee. OWASP также предоставляет лучшие практики TLS .

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

Ниже приведены рекомендации по защите конфиденциальных данных:

  • Используйте платформу, поддерживающую односторонний и двусторонний TLS, которая будет обеспечивать защиту на уровне протокола.
  • Используйте такие политики, как политика AssignMessage и политика JavaScript, чтобы удалять конфиденциальные данные перед их возвратом клиенту.
  • Используйте стандартные методы OAuth и рассмотрите возможность добавления HMAC, хэша, состояния, nonce, PKCE или других методов для повышения уровня аутентификации для каждого запроса.
  • Используйте настройки маскировки данных , чтобы замаскировать конфиденциальные данные в инструменте Edge Trace.
  • Будьте осторожны при хранении конфиденциальных данных в кеше (или шифруйте конфиденциальные данные, хранящиеся в кеше). В Edge вы можете зашифровать хранящиеся конфиденциальные данные в картах значений ключей .

A4:2017 – Внешние объекты XML

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

Политика Apigee ExtractVariables позволяет извлекать содержимое из запроса или ответа и назначать это содержимое переменной. Вы можете извлечь любую часть сообщения, включая заголовки, пути URI, полезные данные JSON/XML, параметры формы и параметры запроса. Политика работает путем применения текстового шаблона к содержимому сообщения и, при обнаружении совпадения, установки переменной с указанным содержимым сообщения.

Apigee имеет встроенный анализатор XML как часть платформы, которая использует XPath для извлечения данных. Он также имеет политику XMLThreatProtection для защиты от вредоносных полезных данных XML.

A5:2017 - Нарушен контроль доступа

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

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

Элементы управления доступом для пользовательского интерфейса Edge

Контроль доступа для портала разработчиков Apigee

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

Контроль доступа для доступа к API среды выполнения Apigee

  • Доступ к API можно обеспечить с помощью ключей API, токенов OAuth, областей OAuth, сертификатов и других методов.
  • Поставщик API настраивает доступные ресурсы, определяя продукт API . Доступ предоставляется либо вручную в пользовательском интерфейсе, через API управления, либо через портал разработчика. Когда приложению разработчика предоставляется доступ к продукту API, оно получает идентификатор клиента и секретный код, которые используются в процессе аутентификации.
  • Apigee может интегрироваться с любым поставщиком удостоверений для выполнения OAuth.
  • Apigee может генерировать токены JWT или использовать другие методы для отправки идентификационных данных пользователя целевым службам. Целевые службы могут использовать это удостоверение для ограничения доступа к службам и данным по мере необходимости.

A6:2017-Неправильная конфигурация безопасности

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

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

Релизы продуктов Apigee обеспечивают защиту от библиотек с уязвимостями. Apigee может выпустить дополнительные исправления или обновления, если будут обнаружены новые уязвимости. Публичное облако Edge обновляется автоматически. Клиенты Edge для частного облака (локально) должны самостоятельно устанавливать исправления для продукта.

A7:2017-Межсайтовый скриптинг (XSS)

Межсайтовый скриптинг (XSS) позволяет злоумышленникам выполнять скрипты в веб-браузерах пользователей для управления пользовательскими сеансами, манипулирования веб-сайтами или других способов злонамеренного воздействия на пользователей. Проблемы XSS не обязательно связаны с API, но Apigee предоставляет политики защиты от угроз, которые можно использовать для защиты от XSS в API. Используя регулярные выражения с помощью политики RegularExpressionProtection или политики JavaScript , проверьте полезные данные и значения параметров на наличие JavaScript и других атак типа внедрения.

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

A8:2017 — Небезопасная десериализация

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

Apigee не рекомендует десериализацию. Однако политика JSONThreatProtection и политика RegularExpressionProtection могут помочь защититься от вредоносных полезных данных JSON. Политику JavaScript также можно использовать для сканирования полезных данных на наличие вредоносного содержимого. Кэш и другие политики могут использоваться для защиты от атак повторного воспроизведения. На уровне инфраструктуры платформа Apigee также имеет встроенные средства защиты запущенных процессов.

A9:2017 - Использование компонентов с известными уязвимостями

Поскольку платформы, библиотеки и модули работают с полным выполнением и доступом CRUD, злоумышленники могут использовать уязвимости компонентов для атаки на системы.

Регулярные выпуски продуктов Apigee обеспечивают защиту от уязвимостей компонентов, особенно при обнаружении конкретных уязвимостей. Публичное облако Apigee обновляется автоматически, и Apigee уведомляет клиентов Edge for Private Cloud, когда локальные исправления доступны для установки.

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

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

Apigee имеет несколько способов ведения журнала, мониторинга, обработки ошибок и ведения журнала аудита.

Ведение журнала

  • Сообщения журнала можно отправлять в Splunk или другую конечную точку системного журнала с помощью политики MessageLogging .
  • Данные аналитики API можно получать через API аналитики , а также импортировать или экспортировать в другие системы.
  • В Edge для частного облака вы можете использовать политику MessageLogging для записи в локальные файлы журналов. Также доступны файлы журналов каждого из работающих компонентов.
  • Политику JavaScript можно использовать для отправки сообщений журнала в конечную точку ведения журнала REST синхронно или асинхронно.

Мониторинг

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

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

Журналы аудита

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

Решения Apigee для устранения уязвимостей OWASP 2013 г.

Когда OWASP обновил свой список за 2017 год, некоторые уязвимости из списка 2013 года были исключены. Они по-прежнему представляют собой реальную угрозу. В следующих разделах описывается, как бороться с этими угрозами с помощью Apigee.

A8:2013 — Подделка межсайтового запроса (CSRF)

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

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

  • Это скорее проблема браузера, а не проблема продукта API. Вы можете устранить эту уязвимость с помощью OpenID Connect, OAuth и других методов.
  • Рассмотрите возможность использования методов HMAC, состояния, хэша, nonce или PKCE для предотвращения атак подделки и повторного воспроизведения.

A10:2013 – Непроверенные редиректы и переадресации

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

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

  • Используйте OAuth и выполняйте проверку при каждом запросе.
  • Предотвратите неожиданные 302-перенаправления, проверяя коды ответов в логике прокси-сервера API и соответствующим образом обрабатывая перенаправления.