Всем привет! На связи Денис Кириллов, главный архитектор Platform V SOWA в СберТехе. Наше решение — это высокопроизводительный, гибкий и надежный шлюз безопасности API.
Недавно мы с вами начали обсуждать способы защиты API в современном мире. Я рассказал о принципах безопасности API, о том, как спецификации API влияют на его защищённость и как валидация на соответствие спецификации помогает минимизировать потенциальные риски.
Сегодня поговорим о проблемах валидации API и совместном использовании механизмов валидации и WAF. Разберёмся, почему необходим внешний компонент для валидации, который реализовывал бы функцию безопасности по отношению к API. И рассмотрим возможности продукта, который мы создали для решения этих задач.
Если работаете в области информационной безопасности, сопровождения и разработки, то материал будет для вас особенно полезным.
Проблемы валидации API
Как мы уже говорили, валидация помогает устранить потенциальные риски безопасности. Но иногда при валидации API возникают проблемы. Их можно условно разделить на две группы:
Отсутствие или неполнота спецификации. Например, когда спецификация не затрагивает функции безопасности или соответствует какому-то стандарту, но в ней нет возможности задать ограничения.
Рассинхронизация спецификации и реализации: в спецификации прописано одно, а реализовано другое.
Почему так получается? Причин может быть несколько:
Спецификация не может быть использована и реализована как есть, или существуют программные ограничения.
При подходе Doc-first используются генераторы кода по спецификации, а они не всегда могут корректно обработать задаваемые ограничения.
При подходе API-first спецификация тоже может быть сгенерирована не совсем корректно.
Проверки «размазываются» по коду, когда при заданных условиях разработчик реализует спецификацию по-своему. Например, это может происходить потому, что некоторые ограничения не генерируются автоматически. И трудно адекватно оценить, реализуется то или иное ограничение или нет.
Концентрация на функциональности с игнорированием ограничений. В качестве примера — случай с additionalProperties, о котором говорили в первой статье. Вкратце напомню: при разрешении дополнительных свойств объекта управлять изменениями становится проще, потому что ничто не мешает добавлять новые свойства, не внося изменений в схему валидации. Но с точки зрения безопасности это неудачный вариант: мы теряем возможность контролировать структуру объекта.
Давайте подробнее рассмотрим несколько случаев. Приведу пример из моей личной практики, когда спецификация не использовалась как есть.
В верхнем фрагменте кода на скриншоте аналитик хотел сделать красивую и понятную визуализацию спецификации: чтобы параметры, их обязательность и тип хорошо считывались. Поэтому разработчик параллельно определил все параметры как фактические параметры запроса и продублировал их в тело запроса.
Если бы разработчик оставил только второй, корректный вариант (нижний фрагмент кода), то не было бы понятно, какие элементы в интерфейсе обязательные, а какие нет. Разработчику приходится вручную оставлять только те ограничения, которые предполагались изначально. Но насколько они корректны — большой вопрос с точки зрения дальнейшего использования. И как раз поэтому подход API-first может стать проблемой.
Другой вариант — сначала разработать код и уже по нему генерировать спецификацию. Пример с OpenAPI: генератор не всегда корректно создаёт ограничения, отображаемые потом в спецификации. Ограничения обрабатываются на уровне кода: то, что мы увидим в коде и в спецификации, может иметь разный смысл. Соответственно, ограничения, которые реализуются в коде, в спецификации могут никак не присутствовать.
Те же самые проблемы есть и при подходе Doc-first. Я часто сталкивался с тем, что описание спецификации OpenAPI прогоняется через генератор. А генератор тоже может по-разному трактовать размер, количество элементов и прочие параметры. Проверки, которые задаются и описываются в спецификации, могут реализовываться не так, как запланировано. Например, при реализации разработчик может вносить изменения в ограничения, потому что считает, что так правильнее.
Я сталкиваюсь с тем, что в большинстве случаев до сих пор используется API-first подход. Но при этом API реализуется независимо от документации, а спецификация генерируется позже и в итоге может не соответствовать той, которую изначально определяют аналитики.
Отдельный момент — валидаторы могут проверить не всё, что нужно проверять. Частично проверка должна происходить на этапе парсинга. Это, в основном, касается противодействия DDoS-атакам седьмого уровня: сначала нужно распарсить содержимое, а ограничение обычно задаётся на уровне парсера.
Нужно также учитывать, что валидаторы и сами могут содержать уязвимости и быть потенциальным уязвимым звеном. Их некорректные настройки также могут приводить к реализации угроз безопасности.
Как валидация помогает WAF
Валидация благодаря своей позитивной модели позволяет сократить пространство проверки данных для WAF. На скрине ниже мы видим исходный объект с простыми структурами данных. Все элементы имеют либо int-значения, либо строго определённый формат. И только одно поле содержит текст в свободной форме. Если в таком массиве будет 100 тысяч записей, и все их отправить на WAF для поиска инъекций, это заставит его сильно задуматься. Всё-таки WAF содержит требовательные к ресурсам механизмы для достаточно глубокой проверки.
Если мы зададим схему валидации, которая по позитивной модели как минимум отфильтрует большую часть запросов и данных из oid, amount и quantity, то для WAF это может быть единственное поле, которое нужно проверить на потенциальные инъекции.
Зачем нужен внешний компонент для валидации
Но иногда валидации на уровне приложений недостаточно, требуются внешние компоненты. И вот почему:
То, что задаётся в стандартных спецификациях, не всегда содержит все необходимые с точки зрения безопасности проверки.
В рамках модели Zero Trust мы не можем доверять самому приложению, потому что не знаем, как разработчик реализовал те или иные ограничения.
Внешние компоненты валидации — это дополнительный уровень контроля.
А ещё это проверка ограничений совместно с поиском потенциальных инъекций.
Потенциально вредоносное и некорректное содержимое не допускается в защищаемый периметр.
Внешним компонентом валидации может выступать API-шлюз. Такой шлюз безопасности представляет собой централизованную точку контроля, безопасности и управления потоками взаимодействия. Он позволяет применить политики аутентификации, авторизации, фильтрации трафика, квотирования и троттлинга для защиты функциональности API. API-шлюз предоставляет функциональность журналирования и мониторинга, которая необходима для аудита и расследования инцидентов, в том числе инцидентов безопасности.
Валидация с помощью Platform V SOWA
В качестве внешнего компонента валидации мы в СберТехе разработали решение Platform V SOWA. Это шлюз безопасности API, который поддерживает различные протоколы программного взаимодействия и реализует функции интеграции между API.
Мы встроили в продукт как возможности валидации, так и интегрированный WAF. Это позволяет нам придерживаться концепции совместного использования. Решение позволяет определять контекстно-зависимые проверки, в том числе по отношению к валидации.
Как любой уважающий себя шлюз безопасности API, Platform V SOWA позволяет использовать вложенные механизмы проверки для сложных структур данных и стандартно лимитировать запросы, в том числе с точки зрения противодействия L7 DDoS.
Ключевые сервисы Сбера уже более семи лет используют Platform V SOWA для общения с внешним API и защиты информации. Решение показало достаточно высокий уровень отказоустойчивости — 99,99 %. Это максимальная доступность клиентских систем на уровне программного обеспечения, достигаемая в зависимости от используемой инфраструктуры развёртывания платформы. Продукт зарегистрирован в российском реестре ПО и обеспечивает высокий уровень безопасности, который подтверждён различными тестированиями. Но на этом мы не останавливаемся и продолжаем развивать и тестировать продукт.
Что касается валидации на соответствие спецификации, продукт поддерживает много стандартов. Это и обычные JSON с XSD, и WSDL, и OpenAPI & Swagger, и GraphQL, и Protobuf. По запросу мы достаточно активно добавляем новые варианты для проверки структурированных данных на соответствие тому или иному формату.
С точки зрения валидации Platform V SOWA предлагает дополнительную функциональность. Например, можно добавлять ограничения, которые не покрываются стандартными схемами валидации. Можно извлекать отдельные элементы, конвертировать их в другие форматы, валидировать и фильтровать. Доступна валидация и запросов, и ответов при соблюдении модели Zero Trust.
Также можно задавать ограничения на уровне парсера и валидатора: запрет на загрузку внешних схем валидации, на использование DTD в XML, запрет ссылок на внешние сущности и так далее. То есть всё то, что превентивно должно противодействовать L7 DDOS.
А что по конфигурации?
Конфигурация продукта представляет собой метасхему над схемой API: валидация по OpenAPI-спецификации размещается посередине. Мы можем дополнять цепочку проверками, которых в самой схеме валидации нет. При этом выполняется валидация на соответствие схеме в OpenAPI. Параллельно идёт поиск инъекций. Всё это встраивается в единую цепочку, формируя ту самую метасхему API.
Структурно и архитектурно валидация с помощью Platform V SOWA выглядит следующим образом. Запросы поступают в движок безопасности и валидируются. При необходимости извлекаются отдельные элементы, их содержимое преобразовывается в другой формат, отправляется в другой валидатор, и параллельно может направляться на тестирование.
Ниже пример того, как задаются ограничения на количество запросов в GraphQL. На иллюстрации показано, как можно при валидации задать максимальное количество GraphQL-запросов.
Иногда API агрегируют ответы от совершенно разнотипных сервисов. Например, внутри ответа от JSON-сервиса содержится элемент с ответом от другого внешнего сервиса. Он кодирован в Base64, а внутри на самом деле лежит XML. То есть это XML, который генерируется в ответ от других внешних сервисов.
На самом деле так бывает довольно часто. С такими сложными структурами мы тоже умеем работать. Мы последовательно валидируем сначала тело запроса целиком на соответствие JSON-схеме валидации. Затем извлекаем отдельный элемент с использованием выражения JSON-path, декодируем его из Base64. А затем к полученным данным применяем валидацию на соответствие схеме XSD.
Ещё мы можем проводить контекстно-зависимые проверки. Например, получая JSON и используя JSON-класс выражения мы можем сравнить его с переменными, которые, скажем, содержат текущую группу пользователей. В зависимости от вычисленного значения переменной можно настроить различные условия на допустимые значения параметра responseRecordCount, то есть для разных групп пользователей можно нарезать разные ограничения. Получается, что с одной стороны, это процедура валидации, а с другой — та самая авторизация на уровне свойств объектов.
Заключение
В этой статье мы разобрали, какие бывают проблемы валидации API и почему они возникают. Выяснили, какие возможности даёт совместное использование валидации и WAF и почему для обеспечения безопасности недостаточно только валидации на уровне приложений. Разобрались, что для валидации важно иметь отдельный внешний компонент, и познакомились с продуктом Platform V SOWA, который СберТех разработал для решения этой задачи.
Среди прочих преимуществ Platform V SOWA — возможность комбинировать позитивную и негативную модели безопасности, гибко настраивать политики управления, контроля и безопасности, а также широкий спектр прикладных протоколов (включая Kafka и различные MQ) и возможность их конвертации. Чтобы больше узнать о продукте и его возможностях, записывайтесь на демо. Там мы с коллегами расскажем подробнее про сценарии использования продукта.
И остаёмся на связи: в следующей статье расскажем о безопасном взаимодействии с GenAI: проблемах, решениях и практических сценариях.
Спасибо за внимание!