Использование gRPC API становится все более распространенным, однако мифы относительно тестирования их безопасности до сих пор требуют опровержения. Если относиться к ним как к обычным REST API, значительная часть поверхности атаки может остаться неисследованной.
В статье объясняется, как комплексно тестировать gRPC API на наличие уязвимостей, а также что важно учитывать во время этого процесса.
Почему gRPC усложняет традиционное тестирование безопасности?
gRPC API усложняют традиционное тестирование безопасности, поскольку они не соответствуют предположениям, на которых базируется много старых инструментов: предсказуемые URL-адреса, простая модель “запрос-ответ” и полезная нагрузка в формате JSON через HTTP.
gRPC обычно использует HTTP/2 и Protocol Buffers, поэтому запросы являются бинарными, а не текстовыми, строго типизированными и определяются описаниями сервисов, а не через обычные маршруты в стиле REST.
Тестирование gRPC требует понимания сервисов, методов, структур сообщений, особенностей потоковой передачи данных и средств контроля безопасности транспортного уровня.
Злоумышленники могут атаковать открытые методы сервисов, слабые механизмы авторизации на уровне методов, небезопасную обработку Protobuf, незащищенные настройки транспортного уровня и серверную рефлексию. Стриминговые методы также могут создавать риски долговременных соединений и управления состояниями, которых не существует в простых API с моделью “запрос-ответ”.
Тестирование безопасности gRPC API
Серверная рефлексия gRPC (Server reflection)
Необходимо проверить, включена ли серверная рефлексия и не раскрывает ли она лишнюю информацию недоверенным пользователям.
Серверная рефлексия позволяет клиентам получать описания сервисов без необходимости доступа к файлам Protocol Buffer. Это упрощает разработку и устранение неисправностей, но в то же время может помочь злоумышленникам обнаружить доступные сервисы и методы.
Серверную рефлексию часто описывают как аналог introspection в GraphQL для gRPC, поскольку этот механизм позволяет понять структуру и функциональные возможности приложения.
Тестирование должно определить:
- Включена ли рефлексия в рабочей среде
- Требует ли рефлексия аутентификации
- Могут ли пользователи с низким уровнем привилегий получать перечень сервисов
- Доступны ли сугубо внутренние методы
- Раскрывает ли рефлексия устаревшую или незадокументированную функциональность
Если рефлексия является общедоступной, злоумышленники могут обнаружить административные методы, скрытые API или связи между сервисами, которые иначе было бы трудно найти.
Сама по себе серверная рефлексия не является опасной. Однако в рабочей среде следует тщательно контролировать, кто имеет к ней доступ и при каких условиях.
Тестирование аутентификации и авторизации
Следует убедиться, что каждый метод gRPC обеспечивает надлежащую аутентификацию, авторизацию и проверку идентичности.
Многие развертывания gRPC полагаются на межсервисное взаимодействие, где аутентификация происходит на нескольких уровнях. Во время тестирования нужно проверять как средства контроля авторизации для пользователей, так и доверительные отношения между сервисами.
Основные направления проверки включают:
- Отсутствие обязательной аутентификации
- Слабую валидацию токенов
- Ошибки в авторизации на основе ролей
- Межтенантовый доступ
- Обход авторизации на уровне методов
- Неправильное использование сервисных аккаунтов
- Повышение привилегий через цепочки вызовов между сервисами
В отличие от REST API, приложения gRPC часто реализуют авторизацию с помощью перехватчиков, промежуточного программного обеспечения или политик сервисной сетки. Во время тестирования безопасности необходимо убедиться, что эти средства контроля последовательно применяются ко всем методов, а не только к отдельным сервисам.
Авторизация на уровне методов заслуживает особого внимания. Часто встречаются сервисы, где большинство методов применяют контроль доступа, тогда как реже используемый административный метод этого не делает.
Безопасность транспортного уровня и валидация mTLS
Нужно проверить конфигурацию TLS, обработку сертификатов и средства контроля mTLS (взаимная аутентификация TLS).
Многие современные среды gRPC в значительной степени полагаются на TLS и mTLS как на основные механизмы безопасности. В архитектурах сервисной сетки mTLS может служить главным механизмом для проверки идентичности сервисов и контроля доверенных каналов связи.
Во время тестирования следует оценивать:
- Версию TLS и конфигурацию шифров
- Механизм валидации сертификатов
- Цепочки доверия сертификатов
- Механизмы ротации сертификатов
- Требования к клиентским сертификатам
- Проверку идентичности сервисов
- Логику авторизации на основе перехватчиков
- Политики безопасности сервисной сетки
Неправильно настроенный mTLS создает ложное чувство безопасности. Сервис может принимать сертификаты от неавторизованных клиентов, доверять слишком широкому перечню центров сертификации или неправильно проверять идентичность другого сервиса. При таких условиях злоумышленники могут выдавать себя за доверенные сервисы.
Тестирование взаимодействия с сохранением состояния и рабочего процесса
Многие среды gRPC опираются на последовательности вызовов сервисов, которые совместно обеспечивают авторизацию, бизнес-логику или целостность транзакций. Уязвимости могут возникать только тогда, когда запросы выполняются в определенном порядке или в условиях взаимозависимого выполнения.
Во время тестирования необходимо убедиться, что разрешения остаются согласованными на всех этапах рабочего процесса. Также следует проверить, не приводят ли повторно отправленные или выполненные в иной последовательности запросы к ненадежным результатам.
Механизмы контроля, зависящие от состояния системы, должны правильно работать даже под нагрузкой. Это особенно важно в микросервисных средах, где решения по безопасности могут приниматься несколькими различными сервисами.
Тестирование безопасности потоковых методов
Необходимо проверить потоковую передачу со стороны клиента, со стороны сервера и в обоих направлениях.
Одной из определяющих характеристик gRPC является поддержка долговременных потоковых коммуникаций. Клиентский стриминг принимает несколько сообщений перед возвращением ответа. Серверный стриминг возвращает клиенту последовательность сообщений, а двунаправленный стриминг позволяет обеим сторонам обмениваться данными одновременно. Все эти методы создают риски безопасности, отсутствующие в традиционных API типа “запрос-ответ”.
Тестирование должно быть сосредоточено на:
- Авторизации на протяжении всего жизненного цикла потока
- Обработке окончания срока действия сессии
- Обработке окончания срока действия токена
- Ограничениях количества соединений
- Рисках истощения ресурсов
- Ограничениях размера сообщений
- Контроле потока данных
- Возможностях несанкционированного перехвата потока
Долговременные потоки создают возможности для атак типа “отказ в обслуживании” и отклонений в авторизации, когда пользователь, имевший права в начале потока, может потерять этот статус позже (например, из-за отзыва учетных данных или изменения разрешений во время стриминга). Средства безопасности должны учитывать изменение разрешений, отозванный доступ и просроченные учетные данные.
Тестирование Protobuf-сообщений и их валидация
Следует проверить, как сервисы обрабатывают некорректные, неожидаемые или экстремальные входные данные Protocol Buffer.
Protocol Buffers обеспечивают строгую типизацию, однако недостатки реализации все равно способны порождать уязвимости. Эффективный фаззинг направлен на структуры сообщений, а не просто на отправку случайных данных.
Тестирование должно фокусироваться на:
- Граничных значениях целых чисел
- Обработке Enum и неожиданных значениях Enum
- Повторяющихся полях
- Глубоко вложенных сообщениях
- Больших полезных нагрузках
- Необязательных и отсутствующих полях
- Обработке неизвестных полей
- Сценариях путаницы типов
Тестирование Enum является особенно полезным, поскольку приложения иногда предполагают, что возможны только задокументированные состояния. Неожиданные или нераспознанные значения способны выявить недостатки валидации и логические ошибки.
Цель заключается в выявлении::
- Сбоев и аварийного завершения работы
- Ошибок при разборе сообщений
- Обхода механизмов валидации
- Условий, приводящих к истощению ресурсов
- Неожиданных переходов между состояниями
- Логических ошибок, вызванных некорректно сформированными данными
Особое внимание следует уделять вложенным структурам и повторяющимся полям. Они могут вызывать чрезмерное потребление памяти, проблемы с рекурсией или непоследовательную проверку данных.
Тестирование инъекций в сервисах gRPC
Хотя gRPC использует строго типизированные сообщения Protobuf, а не параметры запроса, базовые риски остаются по большей части такими же, как и в GraphQL и REST API.
Методы сервисов, которые передают контролируемые пользователем входные данные в базы данных, поисковые платформы, внутренние сервисы, команды операционной системы или облачные ресурсы, все еще могут быть уязвимыми к SQL-инъекциям, инъекциям команд, SSRF и связанным недостаткам.
Во время проверки gRPC API фокус должен быть на том, как поля Protobuf обрабатываются последующими компонентами, вместо того, чтобы считать, что структурированные сообщения полностью устраняют риск инъекций.
Вывод
gRPC API предоставляют мощные возможности для разработки современных приложений, но в то же время могут создавать риски, которые традиционное тестирование безопасности может не обнаружить.
Компании, которые относятся к ним так же, как к REST API, рискуют оставить без внимания важные части своей поверхности атаки.
Для автоматизированного и точного тестирования gRPC API на наличие уязвимостей существует возможность бесплатно протестировать Invicti (на базе Acunetix и Netsparker). Для этого необходимо оставить контактные данные ниже:
