Активная защита API: сканер уязвимостей нового поколения от Cloudflare

Безопасность традиционно играет в защиту. Вы строите стены, устанавливаете ворота и пишете правила для блокировки подозрительного трафика. Уже много лет Cloudflare является лидером в этой области: наша платформа Application Security предназначена для перехвата атак в полете, отсеивая вредоносные запросы на периметре до того, как они достигнут вашего источника. Но для безопасности API оборонительной позиции недостаточно.

Вот почему сегодня мы запускаем бета-версию Сканера уязвимостей Cloudflare для веб-приложений и API.

Мы начинаем с самой распространенной и трудноуловимой угрозы из OWASP API Top 10: Broken Object Level Authorization, или BOLA. Со временем мы добавим больше типов сканирования уязвимостей, включая угрозы как для API, так и для веб-приложений.

Самые опасные уязвимости API сегодня — это не общие инъекционные атаки или некорректные запросы, которые WAF легко обнаруживает. Это логические ошибки — совершенно валидные HTTP-запросы, которые соответствуют протоколу и спецификации приложения, но нарушают бизнес-логику.

Чтобы найти их, нельзя просто ждать атаки. Нужно активно их выслеживать.

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

В мире веб-приложений уязвимости часто выглядят как синтаксические ошибки. Попытка SQL-инъекции выглядит как код там, где должны быть данные. Межсайтовый скриптинг (XSS) выглядит как тег скрипта в поле формы. У них есть сигнатуры.

С уязвимостями API всё иначе. Для наглядности представим мобильное приложение доставки еды, которое общается исключительно с API на бэкенде. Возьмём эндпоинт заказов:

Определение эндпоинта: /api/v1/orders

При атаке с нарушением авторизации, такой как BOLA, Пользователь А (злоумышленник) запрашивает обновление адреса доставки оплаченного заказа, принадлежащего Пользователю Б (жертва). Злоумышленник просто подставляет {order_id} Пользователя Б в запрос PATCH.

Вот как выглядит этот запрос, где '8821' — это ID заказа Пользователя Б. Обратите внимание, что Пользователь А полностью аутентифицирован со своим собственным валидным токеном:

PATCH /api/v1/orders/8821 HTTP/1.1
Host: api.example.com
Authorization: Bearer <User_A_Valid_Token>
Content-Type: application/json

{
  "delivery_address": "123 Attacker Way, Apt 4",
  "instructions": "Leave at front door, ring bell"
}

Заголовки запроса валидны. Токен аутентификации валиден. Схема верна. Для стандартного WAF этот запрос выглядит идеально. Предложение по управлению ботами также может быть обмануто, если человек отправляет атакующие запросы вручную.

Теперь еда Пользователя Б будет доставлена Пользователю А! Уязвимость существует потому, что конечная точка API не проверяет, имеет ли Пользователь А разрешение на просмотр или изменение данных пользователя Б. Это ошибка логики, а не синтаксиса. Чтобы исправить это, разработчик API мог бы реализовать простую проверку: if (order.userID != user.ID) throw Unauthorized;

Обнаружить такие уязвимости можно, активно отправляя тестовый трафик API или пассивно прослушивая существующий трафик API. Для поиска этих уязвимостей с помощью пассивного сканирования требуется контекст. В прошлом году мы запустили обнаружение уязвимостей BOLA для API Shield. Это обнаружение автоматически находит такие уязвимости, пассивно сканируя трафик клиентов на аномалии в использовании. Для успеха такого сканирования необходимо знать, как выглядит "валидный" вызов API, какие параметры являются переменными, как ведёт себя типичный пользователь и как ведёт себя API при манипуляции этими параметрами.

Тем не менее, у команд безопасности могут быть причины не иметь такого контекста, даже при доступе к обнаружению уязвимостей BOLA в API Shield. Тестовые среды разработки могут нуждаться в проверке, но в них отсутствует пользовательский трафик. В производственных средах может (к счастью) не быть атакующего трафика, но анализ всё равно необходим, и так далее. В таких обстоятельствах, да и в целом для проактивности, команды могут обратиться к динамическому тестированию безопасности приложений (DAST). Создавая совершенно новые профили трафика, предназначенные специально для тестирования безопасности, инструменты DAST могут искать уязвимости в любой среде и в любое время.

К сожалению, у традиционных инструментов DAST высокий порог входа. Их часто сложно настроить, они требуют ручной загрузки и поддержки файлов Swagger/OpenAPI, с трудом проходят аутентификацию в современных сложных процессах входа и могут просто не иметь тестов безопасности, специфичных для API (например, BOLA).

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

Сканирование уязвимостей от Cloudflare отличается по нескольким ключевым причинам.

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

Во-вторых, мы уже знаем входные и выходные данные вашего API. Если вы являетесь клиентом API Shield, Cloudflare уже понимает ваш API. Наши функции API Discovery и Schema Learning пассивно каталогизируют ваши конечные точки и изучают модели трафика. Хотя для начала работы с нашим первым выпуском вам потребуется вручную загрузить спецификацию OpenAPI, в будущем релизе вы сможете начать быстро и без неё.

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

И наконец, мы создали новую stateful (сохраняющую состояние) платформу DAST, как описано ниже. Большинству сканеров требуются часы настройки, чтобы "обучить" инструмент общению с вашим API. С Cloudflare вы можете эффективно пропустить этот шаг и начать быстро. Вы предоставляете учетные данные API, а мы используем схемы вашего API для автоматического построения плана сканирования.

API обычно документируются с использованием схем OpenAPI. Эти схемы обозначают хост, метод и путь (обычно «конечную точку»), а также ожидаемые параметры входящих запросов и результирующих ответов. Чтобы автоматически построить план сканирования, мы должны сначала осмыслить эти спецификации API для любого сканируемого API.

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

Рассмотрим, например, приведенный выше заказ на доставку с ID 8821. Чтобы ресурс на стороне сервера существовал, он должен был быть изначально создан владельцем, скорее всего, в "генезисном" запросе POST с минимальными зависимостями или без них (предыдущие необходимые вызовы и результирующие данные). Если смоделировать API в виде графа вызовов, такая конечная точка представляет собой узел с небольшим количеством входящих связей (зависимостей) или без них. Любой последующий запрос, такой как атакующий PATCH выше, имеет зависимость по данным (данные — это order_id) от генезисного запроса (POST). Без предоставления всех данных запрос PATCH не может быть выполнен.

Здесь фиолетовыми стрелками показаны узлы в этом графе API, которые необходимо пройти, чтобы посетить заказ и добавить к нему заметку через конечную точку POST /api/v1/orders/{order_id}/note/{note_id}. Важно, что ни один из шагов или логики, показанных на диаграмме, не доступен в спецификации OpenAPI! Это должно быть логически выведено каким-либо другим способом, и именно это наш сканер уязвимостей будет делать автоматически.

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

openapi: 3.0.0
info:
  title: Order API
  version: 1.0.0
paths:
  /api/v1/orders:
    post:
      summary: Create an order
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                product:
                  type: string
                count:
                  type: integer
              required:
                - product
                - count
      responses:
        '201':
          description: Item created successfully
          content:
            application/json:
              schema:
                type: object
                properties:
                  result:
                    type: object
                    properties:
                      id:
                        type: integer
                      created_at:
                        type: integer
                  errors:
                    type: array
                    items:
                      type: string
  /api/v1/orders/{order_id}:
    patch:
      summary: Modify an order by ID
      parameters:
        - name: order_id
          in: path

Мы видим, что конечная точка POST возвращает такие ответы, как

{
    "result": {
        "id": 8821,
        "created_at": 1741476777
    },
   "errors": []
}

Для человеческого наблюдателя быстро становится очевидным, что значение $.result.id — это то, что нужно подставить в order_id для конечной точки PATCH. Свойство id также может называться orderId, value или как-то иначе и быть вложено произвольным образом. Эти тонкие несоответствия в документах OpenAPI произвольной формы неразрешимы для подходов, основанных на эвристиках.

Наш сканер использует собственную платформу Cloudflare Workers AI для решения этой нечеткой проблемы. Модели, такие как open-weight gpt-oss-120b от OpenAI, достаточно мощны, чтобы надежно сопоставлять зависимости по данным и генерировать реалистичные фальшивые данные там, где это необходимо, по сути заполняя пробелы в спецификациях OpenAPI. Используя структурированные выходные данные, модель создает представление графа вызовов API для нашего сканера, чтобы он мог его обойти, соответствующим образом внедряя учетные данные атакующего и владельца.

Этот подход решает проблему необходимости человеческого интеллекта для вывода отношений авторизации и данных в схемах OpenAPI с помощью искусственного интеллекта, который делает то же самое. Структурированные выходные данные служат мостом из мира естественного языка gpt-oss обратно к машинно-исполняемым инструкциям. Помимо того, что Workers AI решает проблему планирования, саморазмещение на Workers AI означает, что наша система автоматически получает выгоду от высокодоступной, глобально распределенной архитектуры Cloudflare.

Создание сканера уязвимостей, которому клиенты доверят свои учетные данные API, требует проверенной инфраструктуры. Мы не изобретали велосипед. Вместо этого мы интегрировали сервисы, которые были проверены и развернуты в Cloudflare, для двух ключевых компонентов нашей платформы сканера: плоскости управления сканером и хранилища секретов сканера.

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

Весь бэкенд написан на Rust, который широко используется в Cloudflare для инфраструктурных сервисов. Это позволяет нам повторно использовать внутренние библиотеки и делиться архитектурными паттернами между командами. Это также позиционирует наш сканер для потенциальной будущей интеграции с другими системами Cloudflare, такими как FL2 или наш фреймворк для тестирования Flamingo — позволяя сценариям, где сканирование может более тесно координироваться с обработкой запросов на edge или тестовой инфраструктурой.

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

Мы гарантируем, что наш публичный слой API имеет минимальный доступ к незашифрованным учетным данным клиентов, используя Vault Transit Secret Engine (TSE) от HashiCorp для шифрования как услуги. Сразу после отправки учетные данные шифруются с помощью TSE — который обрабатывает шифрование, но не хранит шифротекст — и затем сохраняются в инфраструктуре Cloudflare.

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

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

Мы выпускаем сканирование уязвимостей BOLA, начиная с сегодняшнего дня, в виде открытой бета-версии для всех клиентов API Shield и работаем над будущими сканированиями угроз для API для последующего выпуска. Через Cloudflare API вы можете запускать сканирования, управлять конфигурацией и получать результаты программно для прямой интеграции в ваши CI/CD пайплайны или панели безопасности. Для клиентов API Shield: ознакомьтесь с документацией для разработчиков, чтобы начать сканировать ваши конечные точки на уязвимости BOLA уже сегодня.

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