Уявіть ситуацію. Команда випустила новий особистий кабінет для клієнтів. Розробники провели десятки code review, DevOps підняли WAF і моніторинг, QA прогнали регресію по кожній кнопці. Реліз пройшов гладко, метрики зелені, у Slack — святкові емодзі.
Через два тижні хтось без жодної авторизації відкриває персональні дані кількох тисяч користувачів. Не через zero-day. Не через обхід WAF за допомогою екзотичного payload'а. Він просто змінив id=1245 на id=1246 в URL — і застосунок чемно віддав йому чужий профіль.
Це не гіпотетична історія — це один із найпоширеніших сценаріїв реальних інцидентів, і має він конкретну назву: Insecure Direct Object Reference (IDOR). За роки роботи з поглибленим аналізом інцидентів я можу впевнено сказати: компанії значно частіше падають не через “голлівудський” експлойт з нульовим днем, а через банальну помилку в логіці авторизації, яку ніхто не помітив, бо вона не ламає жоден тест і не викликає жодного спрацювання за правилами кореляції.
Саме для того, щоб знаходити такі речі до того, як їх знайде хтось інший, і існує пентест вебдодатків. У цій статті — детально про те, що це, за якою методологією працює, які вразливості шукають і що саме ви отримуєте на виході.
Що таке пентест вебдодатків і чим він не є
Пентест вебдодатків (web application penetration testing) — це контрольована, санкціонована спроба “зламати” ваш застосунок так, як це зробив би реальний зловмисник: знайти вразливості, поєднати їх в експлуатований ланцюжок і продемонструвати реальний вплив на бізнес, а не просто скласти список теоретичних недоліків.
Ключове слово тут — санкціонована. Іншими словами, легітимна, підтверджена. Пентестер працює в рамках чітко визначеного скоупу з письмовим дозволом (rules of engagement), і його мета — не завдати шкоди, а показати, що шкоду можна було б завдати і як саме це закрити.
Важливо одразу розвести два поняття, які постійно плутаються — Vulnerability Assessment та Penetration Testing.
Vulnerability Assessment vs Penetration Testing
Vulnerability Assessment (сканування на вразливості) — це автоматизований процес. Сканер (Nessus, Qualys, Burp Scanner тощо) проходить по застосунку, звіряє відповіді сервера з базою відомих сигнатур і патернів і видає список потенційних проблем. Швидко, дешево, добре масштабується. Але сканер не розуміє бізнес-логіку. Він не знає, що користувач A не повинен бачити рахунок користувача B — він бачить лише HTTP 200 і валідний JSON, і для нього це “все ок”.
Penetration Testing (тест на проникнення) — це ручна робота людини (або, як я покажу в кінці, людини разом з AI-агентами), яка думає як зловмисник. Пентестер бере результати сканування як відправну точку, а далі досліджує логіку застосунку, ланцюжки авторизації, стан сесій, поведінку API — і намагається довести експлуатованість (вразливість), а не просто зафіксувати аномалію.
Простий приклад різниці: сканер побачить, що ендпоінт /api/orders/{id} повертає 200 OK, і на цьому зупиниться. Пентестер спробує підставити чужий id, подивиться, чи перевіряється власник ресурсу на бекенді, і якщо ні — це вже не “потенційна проблема”, а робочий Broken Access Control з конкретним доказом.
Обидва підходи потрібні, і вони не взаємозамінні. Сканування на вразливості — це гігієна, яку варто робити регулярно й автоматично. Пентест — це стрес-тест логіки, який показує, що станеться, коли проти вашого застосунку працює мотивована людина.
Методологія: на що спираються пентестери
Хороший пентест — це не хаотичний перебір ідей, а структурований процес, побудований на визнаних індустріальних стандартах.
OWASP Top 10
OWASP Top 10 — це список десяти найкритичніших категорій ризиків для вебзастосунків, який регулярно оновлює OWASP (Open Web Application Security Project) на основі реальних даних про інциденти. Це не чек-лист “перевір ці 10 багів”, а швидше карта категорій ризику: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Software and Data Integrity Failures, Security Logging Failures, Server-Side Request Forgery. Кожна категорія охоплює десятки конкретних технік.
OWASP Top 10 — хороша точка входу для розуміння пріоритетів, але для реального пентесту цього недостатньо.
OWASP WSTG
OWASP Web Security Testing Guide (WSTG) — це вже не список категорій, а детальна методологія тестування: конкретні тест-кейси, згруповані за розділами: Information Gathering, Configuration Management, Identity Management, Authentication Testing, Authorization Testing, Session Management, Input Validation, Error Handling, Cryptography, Business Logic, Client-Side Testing. Кожен розділ описує, що саме перевіряти і якими методами.
Саме WSTG формує “скелет” реального пентесту: коли ви бачите звіт, у якому пункти згруповані за розділами на кшталт “WSTG-ATHN” (тестування автентифікації) або “WSTG-ATHZ” (тестування авторизації) — це ознака того, що робота велася системно, а не за принципом “спробуємо кілька відомих payload'ів і подивимось”.
Black box, gray box, white box
Модель доступу, з якою починає пентестер, суттєво впливає на результат:
- Black box — пентестер не має жодної внутрішньої інформації, тестує застосунок як анонімний зовнішній зловмисник. Максимально реалістично, але дорожче за часом і може не покрити всю логіку.
- Gray box — пентестер отримує обмежений доступ: тестові облікові записи різних ролей, іноді базову документацію API. Це найпоширеніший і найбільш збалансований формат: він імітує реального зловмисника (наприклад, скомпрометованого користувача), але дозволяє покрити значно більше логіки за розумний час.
- White box — повний доступ, включно з вихідним кодом. Використовується рідше для класичного пентесту і частіше поєднується з code review, коли потрібна максимальна глибина.
Для більшості комерційних вебзастосунків оптимальний вибір — gray box: він дає реалістичну картину того, що може зробити авторизований, але недобросовісний користувач, а це саме та модель загроз, яка найчастіше матеріалізується в реальних інцидентах.
Які вразливості шукають у вебдодатках: технічний розбір
Тепер до суті — що конкретно роблять під час пентесту вебдодатка.
SQL Injection
Простими словами — це коли застосунок настільки чемно довіряє тому, що ввів користувач, що вставляє це прямо в запит до бази даних, дозволяючи зловмиснику дописати туди власну команду замість очікуваного імені чи пароля.
SQL-ін'єкції давно перестали бути тим, що показують у мемах про ' OR 1=1--. Сучасні застосунки рідко будують запити наліпом рядків у формі логіну, але ін'єкції нікуди не поділися — вони переїхали. Сьогодні вони ховаються у параметрах сортування (?sort=name), у фільтрах пошуку, які передаються в ORM через “сирі” фрагменти запитів, у JSON-полях, які бекенд згодом підставляє в динамічний SQL, і навіть у HTTP-заголовках, які потрапляють у логуючі запити до бази.
Хороший пентестер не просто запускає sqlmap по кожному параметру — він спершу розуміє, як застосунок формує запити: чи використовуються параметризовані запити (prepared statements) всюди, чи є місця, де ORM “вирветься” на сирий SQL заради оптимізації, і чи є другий порядок ін'єкції (second-order SQLi), коли шкідливі дані спершу зберігаються, а виконуються значно пізніше в іншому контексті.
XSS (Cross-Site Scripting)
XSS — це можливість підкинути свій JavaScript-код у сторінку, яку потім відкриє інший користувач, і змусити цей код виконатися від його імені: вкрасти сесію, підмінити контент чи відправити запит без відома жертви. Це також класика, яка еволюціонувала. Reflected та Stored XSS перевіряють стандартно, але цікавіше — DOM-based XSS, який виникає не на бекенді, а в клієнтському JavaScript, коли дані з URL чи postMessage потрапляють у innerHTML без санітизації. У сучасних SPA на React/Vue/Angular класичний stored XSS трапляється рідше завдяки автоекрануванню фреймворків, зате з'являються нові вектори — через dangerouslySetInnerHTML, кастомні рендери Markdown або бібліотеки третіх сторін, підключені без належного аудиту.
SSRF (Server-Side Request Forgery)
По суті, це коли зловмисник перетворює ваш власний сервер на свого проксі: змушує його самостійно постукати туди, куди зловмисник ніколи б не дістався напряму — у внутрішню мережу за фаєрволом.
SSRF — вразливість, яка недарма потрапила в останній OWASP Top 10 окремим пунктом. Якщо застосунок приймає URL від користувача і сам робить запит за цим URL (наприклад, генерація превʼю посилання, завантаження зображення за посиланням, webhook-інтеграції), зловмисник може підставити внутрішню адресу і змусити сервер звернутися до 169.254.169.254 (metadata endpoint у хмарних провайдерів) або до внутрішніх сервісів, недоступних ззовні. У хмарній інфраструктурі це один із найшвидших шляхів від “нешкідливого” параметра до повної компрометації облікового запису в AWS чи GCP.
XXE (XML External Entity)
Це вразливість XML-парсерів, яка дозволяє підсунути в документ спеціальну “зовнішню сутність” і змусити сервер підтягнути та показати вміст файлу, якого зловмисник бачити не мав би, — від конфігурації до чужих секретів. Менш популярна, ніж раніше, завдяки тому, що JSON витіснив XML з більшості API, але XXE все ще живе там, де застосунки парсять XML, SOAP, SVG-файли або документи Office (які всередині — теж XML). Якщо XML-парсер не налаштований на заборону зовнішніх сутностей, зловмисник може читати локальні файли сервера через <!ENTITY> або спровокувати той-таки SSRF.
IDOR та Broken Access Control
Це та категорія, з якої ми почали статтю, і не випадково — Broken Access Control уже кілька років поспіль займає перше місце в OWASP Top 10. Причина проста: автентифікацію компанії за останні роки навчилися робити доволі добре — MFA, OAuth, надійні бібліотеки. А от з авторизацією все значно складніше, бо кожен застосунок має унікальну модель прав доступу, яку ніхто “з коробки” не перевіряє.
Користувач може бути коректно авторизований і водночас отримати доступ до чужого замовлення, чужого рахунку чи чужого документа, просто підмінивши ідентифікатор або роль у запиті. Пентестер систематично проходить кожен ендпоінт з обліковими записами різних ролей і перевіряє: чи справді бекенд перевіряє власника ресурсу, чи покладається лише на те, що фронтенд не показує “чужу” кнопку.
Authentication issues
Тут перевіряють значно більше, ніж просто “чи можна підібрати пароль”. Це стійкість до brute-force (є rate limiting чи ні), логіка скидання пароля (чи можна підмінити токен скидання, чи витікає він через Referer-заголовок), реалізація JWT (чи перевіряється алгоритм підпису, чи можна підмінити alg: none), поведінка сесій після зміни пароля чи виходу, а також логіка “запам'ятати мене” та багатофакторної автентифікації — чи можна її обійти, повторно відправивши запит без 2FA (двофакторної автентифікації).
Business Logic вразливості
Це найскладніша й найцікавіша категорія, бо вона не автоматизується сканером за визначенням — тут немає сигнатури. Приклади: можливість застосувати промокод кілька разів через паралельні запити (race condition), зміна ціни товару на клієнті перед відправкою в кошик, обхід ліміту спроб через зміну параметра, який, на думку розробника, ніхто не буде чіпати. Такі вразливості знаходять лише через глибоке розуміння того, як застосунок повинен працювати, і систематичний пошук того, де це “повинен” не підкріплене реальною перевіркою на бекенді.
API Security та GraphQL
Сучасний вебдодаток — це в першу чергу набір API, і REST/GraphQL API тестуються окремим блоком. Для REST перевіряють mass assignment (коли можна передати зайве поле в JSON і воно “проковтнеться” бекендом, наприклад, role: admin), відсутність перевірки прав на рівні окремих HTTP-методів, надлишкове розкриття даних у відповідях.
Для GraphQL — свій набір ризиків: introspection, увімкнена на проді (і тоді зловмисник бачить всю схему API як на долоні), відсутність обмежень на глибину і складність запитів (що дозволяє DoS одним важким nested-запитом), а також ті самі проблеми авторизації, тільки тепер на рівні окремих resolver, а не ендпоінтів — і перевірити треба кожен.
Як проходить процес вебдодатку: поетапно
Пентест — це не одна дія, а послідовність фаз, кожна з яких має свою мету.
1. Scoping. Визначається, що саме тестується: домени, піддомени, API, мобільні клієнти застосунку чи в цілому інфраструктура. Узгоджуються вікна тестування, контакти на випадок критичної знахідки, обмеження (наприклад, не чіпати продакшн-платіжний шлюз без попередження). Це найважливіший етап з точки зору юридичної і операційної безпеки — саме тут підписуються rules of engagement.
2. Reconnaissance. Збір інформації про ціль: піддомени, технологічний стек, публічні репозиторії, згадки в мережі, застарілі версії бібліотек. Тут же часто підключається OSINT-складова — перевірка, чи не “ексфільтрувались” секрети компанії в публічний простір ще до початку активного тестування.
3. Mapping / Enumeration. Побудова повної карти застосунку: всі ендпоінти, параметри, ролі користувачів, точки автентифікації. Без якісного мапінгу неможливо систематично покрити застосунок — саме тут відрізняється поверхневий тест від глибокого.
4. Exploitation. Активна фаза: спроби реалізувати вразливості, знайдені на попередніх етапах, і, по можливості, поєднати їх у ланцюжок. Одна вразливість середньої критичності (наприклад, витік внутрішнього ID) у поєднанні з іншою (слабка перевірка авторизації) може дати критичний ланцюжок — і саме демонстрація такого ланцюжка відрізняє пентест-звіт, що впливає на пріоритизацію, від простого списку знахідок.
5. Validation. Кожна знахідка перевіряється на хибнопозитивність (false positive) і на реальний вплив. Тут же оцінюється критичність — зазвичай за CVSS, з поправкою на бізнес-контекст (наприклад, вразливість з формально середнім CVSS, яка веде до витоку персональних даних клієнтів, може бути піднята за критичністю саме через контекст комплаєнсу).
6. Reporting. Формується фінальний звіт (детальніше — нижче).
7. Remediation & Retest. Команда розробки закриває знайдені проблеми, після чого проводиться повторна перевірка (retest) — саме вона підтверджує, що вразливість дійсно закрита, а не просто замаскована.
Що входить у звіт
Гарний звіт про пентест — це не просто PDF зі списком CVE.
Структурно він зазвичай містить:
- Executive Summary — коротке резюме для CTO/CISO без глибокого технічного сленгу: загальний рівень ризику, ключові знахідки, бізнес-вплив.
- Методологію та скоуп — що саме і як тестувалося, з посиланням на OWASP WSTG/Top 10.
- Деталізовані знахідки — для кожної вразливості: опис, кроки відтворення (proof of concept), знімки екрану або запити/відповіді, оцінка критичності (CVSS), вплив на бізнес.
- Рекомендації з усунення — конкретні, а не загальні поради на кшталт “використовуйте параметризовані запити” — з прив'язкою до конкретного місця в коді чи конфігурації.
- Матрицю ризиків — зведену таблицю всіх знахідок за критичністю, зручну для планування спринтів.
- Результати retest — підтвердження, які проблеми закрито, а які потребують додаткової уваги.
Такий звіт легко адаптується під вимоги аудиторів — від ISO 27001 до PCI DSS чи інших вимог — саме тому, що структура вже відповідає очікуваному формату доказової бази.
Скільки триває пентест вебдодатку
Тривалість залежить від розміру застосунку, кількості ролей і глибини бізнес-логіки, але орієнтовно для ручного пентесту терміни наступні:
- невеликий застосунок (сторінка з формою, простий MVP) — 3-5 робочих днів;
- середній SaaS-продукт з кількома ролями та API — 1-2 тижні;
- складна платформа з мікросервісами, кількома клієнтами (web + mobile + API для партнерів) — від 3 тижнів.
Сюди варто закладати окремо час на retest після усунення вразливостей — зазвичай це 20–30% від початкового обсягу робіт.
Щодо AI Pentest від A42, то від триває від 1 до 4 робочих днів з моменту укладання договору та оплати. Дізнатись більше про AI Pentest можна тут.
Чек-лист готовності компанії до пентесту
Перш ніж замовляти тест, варто перевірити кілька речей, це прискорить процес і підвищить якість результату:
- Є тестове або staging-середовище, максимально наближене до продакшну, з реальними обсягами даних (не порожня база).
- Підготовлені тестові облікові записи для кожної ролі — звичайний користувач, адміністратор, гостьовий доступ, партнерський API-ключ.
- Є актуальна документація API (Swagger/OpenAPI, GraphQL schema) — це не обов'язково, але суттєво пришвидшує mapping-фазу.
- Визначені критичні бізнес-процеси, які точно варто перевірити окремо (оплата, зміна email/пароля, видалення акаунта).
- Призначена контактна особа на випадок критичної знахідки, яку потрібно закрити негайно, не чекаючи фінального звіту.
- Узгоджено вікно тестування з командою моніторингу, щоб аналітики SOC не плутали з реальними інцидентами.
Компанії, які проходять цей чек-лист заздалегідь, зазвичай отримують глибший тест за той самий бюджет — просто тому, що менше часу йде на “розвідку боєм” і більше — на реальний пошук вразливостей.
Детальніше про підготовку до пентесту ми розповідаємо в окремій статті.
Як AI змінює пентест вебдодатків
Ось де класична модель пентесту впирається у структурну проблему. Вебдодаток змінюється щодня: нові фічі, нові ендпоінти, оновлені залежності, змінена бізнес-логіка після кожного релізу. А традиційний пентест — це разова подія, яку роблять раз на рік, іноді раз на квартал, якщо пощастить із бюджетом.
Це означає, що між двома пентестами застосунок живе значну частину часу в стані, який ніхто не перевіряв. Реліз, що вийшов на другий день після завершення тесту, отримує нову Broken Access Control вразливість — і про неї ніхто не дізнається до наступного циклу, тобто, можливо, через рік.
Саме цей розрив між швидкістю розробки і швидкістю перевірки закривають AI-агенти. У A42 це реалізовано через мультиагентну систему AI Pentest, де окремі спеціалізовані агенти покривають різні фази класичного пентесту: recon, mapping, exploitation, validation, але роблять це не раз на рік, а безперервно, синхронізуючись з кожним новим релізом.
Наприклад, той самий OSINT-агент, про який ми писали раніше, постійно перевіряє, чи не з'явився витік секретів у публічному репозиторії — задача, яку фізично неможливо покрити разовим ручним тестом, бо витік може статися будь-якого дня між аудитами. Агент, що відповідає за exploitation, валідує знахідки не абстрактно, а перевіряючи реальну експлуатованість — так само, як зробила б людина, тільки без затримки в кілька тижнів на планування.
Це не заміна ручного пентесту там, де потрібна глибока експертиза в складній бізнес-логіці чи нестандартній архітектурі — там людський досвід досі незамінний. Але для покриття OWASP Top 10, регулярної перевірки нових релізів і підтримки безперервного відповідного комплаєнс-статусу AI-агенти дають те, чого не може дати разова перевірка: постійність.
Якщо ваш продукт випускає релізи частіше, ніж раз на рік — а сьогодні так живе майже кожна команда — варто подумати про пентест не як про подію, а як про процес.
Перевіряйте свій вебдодаток безперервно, а не раз на рік — спробуйте AI Pentest на A42.
