Область и подготовка к тестированию GraphQL

Перед началом пентеста GraphQL API необходимо чётко определить границы тестирования и получить письменное разрешение на проведение работ. GraphQL отличается от REST API архитектурой запросов: вместо множества фиксированных эндпоинтов используется единая точка входа, через которую передаются структурированные запросы на языке GraphQL. Это требует адаптации стандартных методик веб-тестирования.

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

  • Получить письменное разрешение на тестирование в рамках авторизованной работы
  • Выключить GraphQL интроспекцию в production-окружении если она предоставляет избыточную информацию
  • Собрать информацию о точке входа API и поддерживаемых операциях
  • Идентифицировать механизмы аутентификации и авторизации

Тестирование аутентификации и авторизации

Механизмы аутентификации в GraphQL API часто реализуются через заголовки HTTP (например, Authorization с bearer-токеном) или cookies. При тестировании необходимо проверить, что запросы без учётных данных отклоняются, а предоставленные credentials корректно валидируются. Попытайтесь отправить запросы с истекшими, поддельными или модифицированными токенами, чтобы убедиться, что сервер отказывает доступ.

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

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

Анализ инъекций и манипуляции с запросами

GraphQL API восприимчива к инъекциям в аргументах запросов, особенно если введённые значения передаются напрямую в SQL, LDAP или другие системы без надлежащей санитизации. Используйте типичные паттерны инъекций: одиночные кавычки, двойные кавычки, звёздочки и специальные символы в текстовых полях. Наблюдайте за сообщениями об ошибках сервера: они часто содержат информацию о структуре БД или логике обработки.

Проверьте возможность перегрузки вычислительных ресурсов через глубоко вложенные запросы (nested query depth) или циклические запросы. GraphQL позволяет запрашивать связанные данные произвольной глубины в одном запросе; без ограничений это может привести к denial of service. Протестируйте отправку запроса с очень большой глубиной вложения или большим количеством параллельных операций в одном HTTP-запросе (query batching).

  • Вводить спецсимволы и кавычки в текстовые аргументы для выявления инъекций
  • Анализировать детальные сообщения об ошибках на предмет утечки информации
  • Проверить ограничения на глубину вложения запросов (query depth)
  • Проверить ограничения на размер запроса и количество одновременных операций

Перечисление и раскрытие информации

GraphQL интроспекция часто включена по умолчанию, позволяя любому клиенту получить полную схему API без аутентификации. Хотя для разработки это удобно, в production-среде раскрытие схемы увеличивает поверхность атаки. Проверьте, доступна ли интроспекция, отправив introspection query; также проверьте, содержат ли сообщения об ошибках информацию о доступных полях или типах.

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

  • Проверить доступность GraphQL introspection query без аутентификации
  • Попытаться перечислить доступные типы, поля и мутации
  • Искать скрытые или недокументированные операции через брутфорс названий
  • Анализировать метаинформацию в заголовках и ошибках ответов

Тестирование бизнес-логики и автоматизация операций

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

Автоматизируйте тестирование, написав скрипты, которые отправляют серии запросов с различными параметрами и анализируют ответы. Обратите внимание на неожиданные изменения состояния системы, конкурентные условия (race conditions) при одновременных операциях и возможность обхода проверок через манипуляцию порядком выполнения мутаций.

  • Выполнять операции в неожиданном порядке для проверки логики состояния
  • Проверить повторную отправку (replay) уже выполненных мутаций
  • Попытаться модифицировать данные других пользователей через неправильную авторизацию
  • Использовать параллельные запросы для выявления race conditions

Анализ ответов и обработка ошибок

GraphQL возвращает ответы в формате JSON с полем 'data' для результатов и 'errors' для сообщений об ошибках. Детальные сообщения об ошибках могут раскрыть информацию о структуре сервера, используемых технологиях или логике обработки. Проверьте, содержат ли ошибки информацию о типах базы данных, путях файловой системы или версиях ПО. Сравните ответы на успешные и неудачные запросы, чтобы выявить различия в поведении, которые могут указывать на информационные утечки.

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

  • Анализировать детальность сообщений об ошибках на предмет информационных утечек
  • Проверить обработку граничных случаев (null, большие значения, спецсимволы)
  • Убедиться, что чувствительные данные не возвращаются неавторизованным пользователям
  • Использовать HTTP-прокси для мониторинга всех аспектов трафика между клиентом и сервером

Документирование результатов и рекомендации

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

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

Источники

PENTEST.RED / RED JOURNAL