Топ-10 угроз для веб-приложений по версии OWASP

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

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

Обзор

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

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

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

  • URL
  • заголовки;
  • Путь
  • Полезная нагрузка

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

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

Решения Apigee для топ-10 OWASP 2017

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

A1:2017 – инъекции

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

Проверять входные данные на платформе Apigee можно несколькими способами:

  • JSONThreatProtection проверяет полезную нагрузку JSON на наличие угроз.
  • XMLThreatProtection проверяет полезную нагрузку XML на наличие угроз.
  • Проверку параметров можно выполнить с помощью JavaScript.
  • Проверку заголовков можно выполнить с помощью JavaScript.
  • Для защиты от внедрения SQL-кода можно использовать правило 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 используются и идентификатор, и секретный код клиента.

OAuth 2.0

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

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

JWT

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

  • Создание токенов JWT (поддерживаются подписи HS256 и RS256)
  • ValidateJWT tokens
  • Декодирование токенов JWT без проверки

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

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

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

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

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

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

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

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

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

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

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

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

Правило ExtractVariables в Apigee позволяет извлекать контент из запроса или ответа и присваивать его переменной. Вы можете извлечь любую часть сообщения, включая заголовки, пути 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) позволяет злоумышленникам выполнять скрипты в веб-браузерах пользователей, чтобы контролировать их сеансы, манипулировать сайтами или наносить вред другими способами. Проблемы с межсайтовым скриптингом не обязательно связаны с API, но Apigee предоставляет правила защиты от угроз, которые можно использовать для защиты от XSS в API. С помощью регулярных выражений, используя правило RegularExpressionProtection или правило JavaScript, проверяйте полезную нагрузку и значения параметров на наличие JavaScript и других атак с внедрением кода.

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

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

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

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

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

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

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

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

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

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

Журналы

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

Мониторинг

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

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

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, состояние, хеш, однократно используемое число или PKCE.

A10:2013 – недействительная переадресация

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

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

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