Використання 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). Для цього необхідно залишити контактні дані нижче:
