Возможность

GraphQL Deep Inspection

Не обрабатывайте GraphQL-трафик как обычное тело POST — перехватывайте интроспекцию, вложенный DoS и паттерны пакетных запросов внутри вашего WAAP.

TR7 GraphQL Deep Inspection не обрабатывает GraphQL-трафик так же, как REST. Единственный GraphQL-эндпоинт, как правило, несёт несколько операций, вложенные запросы, переменные и структуры пакетных запросов — контроли безопасности, останавливающиеся на уровне URL и метода, оставляют критические риски невидимыми. TR7 WAAP использует сигнатурное обнаружение для перехвата попыток интроспекции, паттернов чрезмерно вложенных запросов и поведения пакетных запросов. Расширенные правила TR7 50100, 50101 и 50102 фокусируются на утечке схемы, вложенном DoS и злоупотреблении пакетными запросами соответственно. Контроли GraphQL могут работать по областям query, raw, json и form. Для эндпоинтов вроде `/graphql` политика безопасности может быть ужесточена дополнительно с помощью white-листов методов, проверок разрешённых JSON-ключей, ограничений размера тела и пользовательских правил. Результат: TR7 не претендует на нативный парсер или схема-aware инспекцию полей — но делает наиболее распространённые production GraphQL-риски (интроспекция, вложенный DoS, пакетные запросы) видимыми и управляемыми внутри движка сигнатур WAAP.

Расширенных GraphQL-правила TR7: 50100 интроспекция, 50101 вложенный DoS, 50102 пакетирование

Варианты GraphQL waf_db: семейство 21360 и варианты интроспекции

Области инспекции: query, raw, json, form

GraphQL несёт слишком много возможностей через единственный эндпоинт — классическая логика WAAP упускает большинство из них.

В REST-трафике эндпоинт, метод и путь обычно описывают, что делает запрос. В GraphQL эта информация находится преимущественно в теле. Тот же эндпоинт `/graphql` может нести чтения, записи, вложенные запросы, интроспекцию, фрагменты и операции на основе переменных. Уровень безопасности, проверяющий только URL и метод, не видит, что GraphQL реально делает.

Когда интроспекция GraphQL остаётся открытой в production, схема приложения может утекать. Злоумышленник, узнавший, какие типы, поля и связи существуют, может создавать значительно более целенаправленные запросы. Это может не быть прямой экфильтрацией данных, но это серьёзное раскрытие информации, картографирующее поверхность атак.

Вложенные запросы и фрагменты создают другой риск. Чрезмерно глубокие вложенные запросы могут налагать высокую нагрузку на бэкенд при единственном HTTP-запросе. Стандартное ограничение скорости считает запросы — оно не видит стоимость единственного запроса. В GraphQL риск DoS обычно исходит от структуры запроса, а не от объёма запросов.

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

TR7 GraphQL Deep Inspection изучает GraphQL-трафик с помощью паттерн-основанных WAAP-правил: поведения интроспекции, вложенного DoS и пакетных запросов обнаруживаются по областям query, raw, json и form и привязываются к production-политикам.

Наш подход

TR7 решает проблему безопасности GraphQL не претензией на осведомлённость о схеме, а внедрением наиболее распространённых production-паттернов злоупотребления GraphQL в движок сигнатур WAAP.

Паттерны интроспекции могут быть заблокированы в production

TR7 перехватывает индикаторы интроспекции, такие как `__schema`, `__type`, `IntrospectionQuery` и `fragment FullType`, используя regex-правила. Эти правила могут работать в режиме блокировки в production и в режиме мониторинга или с более низким scoring в staging.

Паттерны вложенного DoS запросов оцениваются и перехватываются

Чрезмерно вложенные GraphQL-запросы могут генерировать высокую нагрузку при едином запросе. Семейство правил TR7 50101 обнаруживает глубокие цепочки `{ ... { ... } }` на уровне паттерна и включает их в решение WAAP с высоким scoring.

Поведение пакетных запросов становится видимым в едином запросе

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

Инспекция области тела ищет GraphQL-нагрузки в нескольких местах

GraphQL-запрос может передаваться не только в теле, но и в полях JSON, формы или строки запроса. Правила TR7 работают по областям query, raw, json и form, подводя различные реализации клиентов под единую политику WAAP.

Возможности

GraphQL Deep Inspection управляет GraphQL-специфическими рисками с помощью сигнатурных WAAP-правил, выбора области и контролей hardening эндпоинтов.

Правило TR7 50100 обнаруживает попытки интроспекции GraphQL

Правило 50100 нацелено на паттерны, обычно используемые при интроспекции GraphQL: `__schema`, `__type`, `IntrospectionQuery` и `fragment FullType`. Уровень риска по умолчанию позиционируется как сигнал средней силы и может оцениваться при scoring 4. На эндпоинтах, где интроспекция должна быть закрыта в production, это правило может работать в режиме блокировки или мониторинга. Попытки обнаружения схемы становятся видимыми в потоке WAAP-событий.

Правило TR7 50101 фокусируется на паттернах вложенного DoS запросов

Правило 50101 обнаруживает чрезмерно вложенные GraphQL-запросы на уровне паттерна. Глубокие цепочки `{` и сильно вложенные структуры могут приводить к тому, что единственный запрос налагает высокую вычислительную стоимость на бэкенд. Это правило может оцениваться при scoring 6 как более сильный сигнал атаки. Цель — не выполнять схема-aware вычисление сложности, а перехватывать опасные паттерны вложенных запросов на ранней стадии.

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

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

Варианты GraphQL из waf_db расширяют покрытие интроспекции и вложенных паттернов

Наряду с расширенными правилами TR7, waf_db содержит варианты GraphQL, такие как семейства 50100, 50101 и 21360+. Эти варианты охватывают альтернативные написания, такие как `__schema {`, `__type`, `__typename` и паттерны вложенных мутаций. Это строит более широкую поверхность сигнатур для интроспекции и поведений вложенных запросов без опоры на единственный regex. Операторы могут переопределять состояние и scoring этих правил на каждый сервис.

Области query, raw, json и form охватывают различные форматы транспорта

GraphQL-запросы не всегда приходят в одном формате. Некоторые клиенты отправляют поля `query`, `variables` и `operationName` внутри JSON-тела; другие могут использовать тело или поля формы. Правила TR7 работают по областям query, raw, json и form, подводя эти различные форматы транспорта под охват инспекции. Это снижает риск ошибки доверия только одному формату тела на GraphQL-эндпоинтах.

Та же модель правил применяется к целям api endpoint и web application

Контроли GraphQL могут применяться к целям api_endpoint и web_application. Та же модель WAAP-правил может управляться с различными значениями состояния, scoring или области в зависимости от типа сервиса. Например, интроспекция может оставаться в режиме мониторинга на внутреннем тестовом эндпоинте, при этом блокируясь на публичном production-эндпоинте. Эта гибкость позволяет единому набору правил адаптироваться к различным политикам среды.

StructureRuleDB может сузить поведение GraphQL-эндпоинта

Для эндпоинта `/graphql` могут быть определены контроли, такие как разрешение только метода POST, ограничение ожидаемых JSON-ключей до `query`, `variables` и `operationName`, или применение ограничения размера тела. Эти контроли не заменяют GraphQL-сигнатуры — они являются слоем позитивной безопасности, дополняющим их. Неожиданные методы или неожиданные JSON-поля могут быть отклонены на ранней стадии, делая поведение эндпоинта более предсказуемым.

Пользовательские правила могут добавлять специфические для приложения GraphQL-паттерны

Если GraphQL-трафик включает специфические для приложения паттерны мутаций, имена полей или рискованные имена операций, они могут быть добавлены как пользовательские WAAP-правила. Например, конкретное ключевое слово `mutation` или чувствительное имя операции, появляющееся в теле, могут получать более высокий scoring. Эти пользовательские правила участвуют в основной системе scoring WAAP и видны в потоке логов и SIEM. Даже без схема-aware инспекции полей специфические для приложения риски могут быть перехвачены с помощью паттерн-основанных правил.

Операционная глубина

GraphQL Deep Inspection основан на сигнатурах в своих текущих реальных возможностях — парсинг операций, вычисление сложности и схема-aware инспекция полей WAAP выходят за рамки этой страницы.

Инспекция на основе паттернов

Контроли GraphQL работают с подходом обнаружения паттернов на основе regex и области. Дифференциация типов операций, реальный счётчик глубины или вычисление scoring сложности запроса не являются частью этой модели. Это различие особенно важно для точного позиционирования.

Переопределение состояния и scoring

Правила 50100, 50101, 50102 и варианты waf_db могут быть установлены в enabled, monitor или disabled в зависимости от потребностей сервиса. Значения scoring также могут быть настроены под допустимость ложных срабатываний приложения. Правильная модель развёртывания для production GraphQL-эндпоинтов — начать в режиме мониторинга и перейти к блокировке после наблюдения реального трафика.

Hardening эндпоинта

White-лист методов, allow-лист JSON-ключей и ограничение размера тела могут применяться на GraphQL-эндпоинтах. Эти контроли обеспечивают соответствие формы запроса ожидаемому контракту наряду с обнаружением сигнатур. На публичных API в частности принятие только ожидаемого формата на эндпоинте `/graphql` сужает поверхность атак.

Граница ограничения скорости

Ограничение скорости на уровне операции не применяется на уровне GraphQL-парсера. Нет претензии на семантический парсинг количества операций внутри единственного тела и применение отдельного ограничения к каждой. Паттерн пакетных запросов может быть перехвачен как сигнатура и использоваться наряду с общими политиками ограничения скорости.

Область persisted запросов

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

Модель без осведомлённости о схеме

Нативная инспекция на уровне конкретного поля GraphQL-схемы — например, `User.email` — не выполняется. Правила работают с подходом сопоставления паттернов по телу. При наличии требований к конкретным полям они должны рассматриваться ограниченным и аккуратным образом с помощью пользовательского regex-правила.

Когда использовать

Блокировка интроспекции на production GraphQL-эндпоинте

Команда безопасности может разрешить интроспекцию в staging, при этом запуская правило 50100 в режиме блокировки на production-эндпоинте. Попытки обнаружения схемы логируются, оцениваются и блокируются по политике.

Блокировка попыток вложенного фрагмента DoS со scoring

Чрезмерно вложенные фрагменты или структуры запросов могут налагать высокую вычислительную стоимость на бэкенд. Правило 50101 перехватывает эти паттерны при scoring 6, обеспечивая сильный сигнал для решения о блокировке WAAP.

Обнаружение атаки пакетных запросов на mobile API

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

White-лист методов и JSON-ключей для GraphQL-эндпоинта

Команда API может разрешить только метод POST и JSON-поля `query`, `variables` и `operationName` на эндпоинте `/graphql`. Неожиданные методы или поля отклоняются до достижения приложения, сужая поведение эндпоинта.

Часто задаваемые вопросы

Поддержка GraphQL в TR7 основана на нативном парсере или паттернах?

Основана на паттернах. TR7 не запускает выделенный парсер операций или движок схема-awareness для GraphQL. Расширенные правила 50100, 50101 и 50102 работают с обнаружением паттернов на основе regex и области. Дифференциация типов операций, реальный счётчик глубины или вычисление сложности запроса не являются частью этой модели. Подход разработан для перехвата наиболее распространённых production-рисков: интроспекция, вложенный DoS и пакетные запросы.

Можно ли полностью закрыть интроспекцию в production?

Да. Правило 50100 нацелено на паттерны `__schema`, `__type`, `IntrospectionQuery` и `fragment FullType`. Возможно запустить это правило в режиме блокировки на production-эндпоинте и в режиме мониторинга на staging-эндпоинте. Попытки обнаружения схемы становятся видимыми в потоке WAAP-событий и блокируются по политике.

Вызывает ли обнаружение пакетных запросов проблемы при легитимном использовании?

Пакетирование запросов может быть легитимным для некоторых клиентов. По этой причине рекомендуется запускать правило 50102 в режиме мониторинга и наблюдать реальное поведение трафика, а не немедленно активировать режим блокировки. После подтверждения злоупотребления правило может быть переведено в политику enabled или block. Значения состояния и scoring могут быть переопределены на каждый сервис.

По каким областям работают правила GraphQL?

Правила GraphQL TR7 работают по областям query, raw, json и form. Независимо от того, передаётся ли нагрузка GraphQL в JSON-теле, теле или полях формы, применяется одна и та же политика WAAP-сигнатур. Различные реализации клиентов подводятся под единый набор правил.

В чём разница между вариантами waf_db и расширенными правилами?

Расширенные правила TR7 (50100, 50101, 50102) позиционируются как основные правила, фокусирующиеся на конкретных паттернах злоупотребления GraphQL. Варианты waf_db охватывают альтернативные написания, такие как `__schema {`, `__typename` и `mutation.*{.*{.*{`, а также дополнительные паттерны интроспекции. Вместе они строят более широкую поверхность сигнатур. Операторы могут управлять обоими уровнями независимо для каждого сервиса.

Как выполняется hardening GraphQL-эндпоинта с помощью StructureRuleDB?

С помощью StructureRuleDB на эндпоинте `/graphql` можно разрешить только метод POST, ограничить ожидаемые JSON-ключи до `query`, `variables` и `operationName`, а также применить ограничение размера тела. Эти контроли не заменяют обнаружение сигнатур — они являются слоем позитивной безопасности, обеспечивающим отклонение запросов с неожиданными методами или полями до достижения ими проверок сигнатур.

Подключите ваши GraphQL-эндпоинты к движку сигнатур WAAP

Сделайте риски интроспекции, вложенного DoS и пакетных запросов видимыми и управляемыми в production. Давайте пройдём через живую настройку на ваших собственных сервисах.