Тестування безпеки API для REST і GraphQL
Для команд, що випускають API REST і GraphQL, це переважно ручний пентест, сфокусований на вразливостях, які пропускають автоматичні сканери: авторизація на рівні об'єкта та функції, зловживання бізнес-логікою й обробка токенів. Ми тестуємо так, як реальний атакувальник із валідним токеном із низькими правами — перебираємо об'єкти, підробляємо особи та зв'язуємо потоки — а потім передаємо відтворювані докази й виправлення, зіставлені з OWASP API Security Top 10 (2023).
Що ми перевіряємо
Зламана авторизація на рівні об'єкта (BOLA/IDOR — API1:2023)
Підміняємо ідентифікатори об'єктів, UUID та вкладені посилання на ресурси між двома акаунтами, доводячи, що один орендар може читати або змінювати дані іншого.
Зламана автентифікація (API2:2023)
Атакуємо вхід, видачу й оновлення токенів: стійкість до credential stuffing, слабкі JWT (alg:none, плутанина HS256/RS256, неперевірені підписи), відсутність спливання/відкликання токенів і обхід OTP/скидання пароля.
Зламана авторизація на рівні властивостей / Mass Assignment (API3:2023)
Впроваджуємо неочікувані поля (role, isAdmin, balance, tenant_id) у запити запису й перевіряємо надмірне розкриття властивостей, яких клієнт не має отримувати.
Необмежене споживання ресурсів (API4:2023)
Перевіряємо відсутність або обхід лімітів запитів, необмежену пагінацію/розмір сторінки та дорогі запити, що дають DoS рівня застосунку й підсилення витрат.
Зламана авторизація на рівні функцій (API5:2023)
Викликаємо адміністративні та привілейовані ендпоінти, заборонені HTTP-методи й приховані функції токеном звичайного користувача, щоб виявити вертикальну ескалацію привілеїв.
Необмежений доступ до чутливих бізнес-потоків (API6:2023)
Зловживаємо потоками — оформлення замовлення, реферали, купони, реєстрація, бронювання — щодо автоматизації та логіки: race conditions і маніпуляції від'ємною кількістю.
Server-Side Request Forgery (API7:2023)
Тестуємо параметри URL/webhook/імпорту на SSRF до метаданих хмари (169.254.169.254), внутрішніх сервісів і DNS-rebinding, включно зі сліпими/out-of-band варіантами.
Специфічні для GraphQL зловживання
Відкрита інтроспекція, атаки глибокою вкладеністю запитів, батчинг аліасів/полів для обходу лімітів та інʼєкції через аргументи резолверів.
Методологія
- 1
Визначення обсягу та авторизація
Письмово узгоджуємо цілі, середовища, тестові акаунти (щонайменше дві ролі/орендарі) та правила проведення, а також підтверджуємо, що ви володієте або уповноважені тестувати API, до надсилання будь-якого трафіку.
- 2
Інвентаризація та розвідка API (API9)
За WSTG перелічуємо ендпоінти з OpenAPI/Swagger, інтроспекції GraphQL, трафіку мобільних/SPA і перехоплення трафіку, зіставляючи версії, shadow- та застарілі ендпоінти.
- 3
Аналіз автентифікації та сесій
Досліджуємо потоки OAuth2/OIDC, структуру й підпис JWT, час життя токена, оновлення та вихід, дотримуючись перевірок WSTG-ATHN/WSTG-SESS.
- 4
Тестування авторизації та бізнес-логіки
Ключова ручна фаза: матриці BOLA/BFLA за ролями й орендарями (WSTG-ATHZ), mass assignment і зловживання чутливими потоками на двох живих акаунтах.
- 5
Інʼєкції, мисконфігурація та споживання
Тестуємо інʼєкції (SQL/NoSQL/command), помилки конфігурації (CORS, докладні помилки, заголовки), ліміти запитів і небезпечне споживання сторонніх API.
- 6
Звіт, ретест і розбір
Кожна знахідка супроводжується доказом запит/відповідь, оцінкою CVSS і рекомендаціями; безкоштовний ретест перевіряє виправлення, після чого йде розбір з інженером.
Стандарти та посилання
Що ви отримуєте
- Технічний звіт — Опис кожної знахідки з кроками відтворення, сирим запитом/відповіддю, оцінкою CVSS і зіставленням з OWASP API/WSTG.
- Резюме для керівництва — Односторінковий виклад ризиків для менеджменту й аудиторів із загальною оцінкою стану та пріоритизованою дорожньою картою усунення.
- Рекомендації з усунення — Конкретні виправлення з урахуванням фреймворку для кожної проблеми — перевірки авторизації, обмеження схеми, посилення токенів — без загальних фраз.
- Безкоштовний ретест і атестація — Повторно перевіряємо усунені знахідки й видаємо лист-атестацію, придатний для клієнтів, партнерів і доказів відповідності.
Часті запитання
Що потрібно надати до початку тесту?+
Середовище staging або близьке до продакшену, документацію API (OpenAPI/Swagger або схему GraphQL, якщо є) та щонайменше два тестові акаунти на роль/орендаря, щоб ми могли довести дефекти авторизації. Для автентифікованих тестів потрібні робочі облікові дані або токени, а дозвіл IP за списками слід підготувати заздалегідь.
Скільки триває пентест API?+
Типове API REST або GraphQL на 30–80 ендпоінтів займає 5–10 робочих днів разом зі звітом. Головні чинники — кількість ендпоінтів, кількість ролей/орендарів і складність бізнес-потоків. Фіксовані строки й ціну ви отримуєте після короткого дзвінка щодо обсягу.
Чи не зламає тест продакшен і чи не витечуть дані?+
За замовчуванням ми тестуємо недеструктивно й узгоджуємо потенційно порушливі перевірки (rate-limit, клас DoS) у сервісному вікні. Бажаний staging; якщо тестуємо продакшен, використовуємо позначені тестові дані й не змінюємо реальні записи клієнтів.
Чи входить безкоштовний ретест?+
Так. Після того як ваша команда виправить знахідки, ми повторно перевіряємо їх без доплати в узгодженому вікні й оновлюємо статус у звіті, даючи доказ, що проблеми справді закриті.
Чи це легально і як оформлюється авторизація?+
Тестування проводиться лише за підписаною згодою та угодою про обсяг, що підтверджує ваше володіння або контроль над ціллю. Це робить роботу законною, точно визначає активи в обсязі й захищає обидві сторони. Увесь час ми дотримуємося суворого документа правил проведення.