Пентест веб-застосунку: де саме ламається захист
Атака на веб-застосунок рідко починається з витонченого зламу. Достатньо надіслати в поле форми рядок із керувальними символами або підмінити параметр у запиті — і застосунок сам віддає те, що користувачеві бачити не належить.
Необроблене введення призводить до підстановки команд, обходу запитів до бази та читання файлів на сервері.
Другий типовий сценарій — слабка перевірка прав. Інтерфейс малює кнопки за роллю, а серверна частина довіряє ідентифікатору із запиту: зміна номера замовлення або профілю в адресному рядку відкриває чужі дані.
Розмежування доступу перевіряють на кожній дії, а не лише на вході до особистого кабінету, — під час тестування на проникнення такі розбіжності знаходяться першими.
Третій шар — застарілі залежності та логіка. Бібліотека з відкритою уразливістю в непрямій залежності живе в проєкті роками, бо напряму її не викликають.
Частина дефектів узагалі не потребує зламу: підміна ціни в прихованому полі, повторний виклик списання, обхід лічильника спроб. Це клас уразливостей веб-застосунків, яких сканер не побачить — він не знає, як задумано вашу логіку.
Тому перевірка захищеності сайту будується як ручна робота за ланцюжками: розвідка, інвентаризація вхідних точок, підвищення прав, доступ до даних, оцінка шкоди.
Такий пентест веб-застосунку дає відтворювані кроки та пріоритет правок — спочатку закривається те, що реально виводить до чужих даних.
Що дає перевірка на проникнення: вимірювані результати
Перевірка на проникнення цінна не списком знайденого, а зміною вимірюваних показників.
До старту фіксуємо базову лінію: скільки часу минає від сигналу про аномалію до блокування, яка частка знахідок закривається за один цикл правок, які класи відмов повторюються від релізу до релізу. Після робіт ті самі метрики вимірюються повторно — різниця і є ефект від пентесту веб-застосунку.
Методика — OWASP Testing Guide: покриваємо автентифікацію, розмежування прав, роботу із сесіями, обробку вхідних даних і конфігурацію серверної частини.
Кожна знахідка описується не позначкою «критично», а сценарієм експлуатації та кроками відтворення — розробник закриває причину, а не симптом.
Ключовий результат — усунений клас відмов. Коли правка йде на рівні загального механізму перевірки прав або валідації входу, зі звіту зникає ціла категорія: повторний прогін тих самих сценаріїв не знаходить споріднених варіантів. Сукупно це і є зниження ризиків веб-застосунку, виражене в цифрах.
Другий ефект — час реакції на інцидент. З відтвореним сценарієм черговий інженер зіставляє сигнал моніторингу з відомим шаблоном і блокує його за хвилини замість годин діагностики.
Ці сценарії ми передаємо в правила виявлення, тому захист продовжує працювати й після завершення робіт.
Формати перевірки: зовнішній контур, внутрішня мережа, цільовий сценарій
Формат перевірки обирають за моделлю загрози: з якої позиції атакувальник бачить систему і що йому вже відомо. Зовнішній аудит периметра повторює роботу стороннього зловмисника — без доступів і вихідного коду, лише публічні адреси.
Внутрішня мережа перевіряється з позиції скомпрометованого співробітника, а цільовий сценарій атаки — з повним доступом до коду й даних.
Чим більше матеріалів передано, тим глибша перевірка і довша робота інженерів. Чорна скринька дає чесну картину зовнішньої захищеності, сіра та біла економлять час і дають змогу дійти до логіки. Набір тестів звіряємо з методикою OWASP.
Порівняння форматів
| Формат | Що знає перевіряльник | Що ловить | Обмеження |
|---|---|---|---|
| Зовнішній аудит периметра, чорна скринька | Лише адреси та публічні інтерфейси | Обхід автентифікації, витоки даних, слабкі налаштування | Не бачить закриті розділи та зв’язки між сервісами |
| Внутрішня мережа, сіра скринька | Тестові облікові записи, частину схем | Підвищення привілеїв, надлишкові права ролей, переміщення між сервісами | Частина шляхів поза охопленням, якщо роль не видано |
| Цільовий сценарій атаки, біла скринька | Код, схеми даних, регламенти | Ланцюжки з кількох дефектів, доведені до доступу до даних | Потрібні доступи до репозиторіїв і час команди на супровід |
На практиці формати комбінують: зовнішній контур показує, що доступно ззовні, цільовий сценарій — чим закінчується ланцюжок. Зводити їх в один етап безглуздо: різна позиція спостерігача дає різні знахідки.
Етапи робіт: від узгодження меж до передавання результатів
Пентест веб-застосунку — це не разовий запуск сканера, а керований цикл із фіксованим порядком кроків. До старту ми узгоджуємо межі перевірки, вікно тестування та відповідальних з обох сторін: без цього будь-яка знахідка виявиться спірною, а роботи — ризиком для робочого сервісу.
- Узгодження меж перевірки. Фіксуємо перелік доменів, піддоменів, програмних інтерфейсів і панелей адміністратора, які входять у периметр, і те, що залишається за ним: зовнішні платіжні шлюзи, чужі сервіси, бойові дані. Окремо проговорюємо правила поводження зі знайденою інформацією.
- Вікно тестування та режим навантаження. Визначаємо інтервали робіт, допустиму інтенсивність запитів, чергового контакту на боці замовника та стоп-сигнал для миттєвої зупинки, якщо поведінка сервісу відхилиться від звичної.
- Розвідка та побудова схеми застосунку. Збираємо маршрути, ролі, точки входу, зовнішні залежності. Схема лягає в основу звіту — за нею видно, які ділянки перевірено, а які ні.
- Перевірка за категоріями. Автентифікація та відновлення доступу, розмежування прав між ролями, обробка користувацького введення, робота із сесіями, конфігурація серверної частини.
- Експлуатація підтверджених знахідок. Уразливість доводиться з мінімальною шкодою: покрокове відтворення, артефакти, оцінка критичності та того, що саме доступно атакувальнику.
- Передавання результатів. Звіт із пріоритетами, відтворюваними кроками та рекомендаціями щодо усунення, плюс розбір із вашою командою розробки.
- Повторна перевірка знахідок. Після виправлень повертаємося лише до закритих пунктів і підтверджуємо результат — інакше не можна відрізнити усунену уразливість від замаскованої.
Модель загроз, ролі доступу та сегментація: що залишається в замовника
Звіт із знайденими уразливостями сам по собі ризик не знижує: за квартал він застаріває, а команда вже не пам’ятає, чому з’явилося те чи інше правило.
Тому пентест веб-застосунку ми закінчуємо не списком зауважень, а набором робочих артефактів, які живуть поряд із кодом і оновлюються разом із ним. Нижче — що саме залишається в замовника і як цим користуватися без нас.
- Схема моделі загроз. Активи, межі довіри, ймовірні сценарії атак і перевірки, які їх закривають; переглядається при зміні архітектури.
- Матриця ролей доступу. Хто до яких даних допущений, де права надлишкові, які прив’язки зняти — таблиця стає основою розмежування.
- Політики доступу. Строк життя секретів, порядок ротації та мінімально необхідні права для сервісних облікових записів, інтеграцій і адмінських панелей.
- Регламент реагування. Що логувати, кому повідомляти і в якій послідовності ізолювати вузол при підозрі на компроміс.
- Інструкції з відтворення. Кроки та очікуваний відгук системи, щоб розробник сам підтвердив, що закриття спрацювало, а не повірив на слово.
- Документація за підсумками перевірки. Критичність знахідок, статус виправлень, залишковий ризик і дата наступної перевірки.
Кожен документ пишемо під ваш стек і ваш процес випуску, із зазначенням власника та точки, де він оновлюється. Так разова перевірка перетворюється на підтримуваний контур контролю, а не на звіт, прочитаний один раз.
Кейс: закрили клас атак на платіжному контурі
Платіжний контур працював на Stripe, і права в ньому перевірялися на боці інтерфейсу: кнопку повернення бачив лише власник платежу, а сервіс приймав ідентифікатор операції з тіла запиту й довіряв йому.
На пентесті це дало прямий обхід авторизації: підмінивши одне поле, запит ішов від імені чужої сесії та проходив — можна було ініціювати повернення або підтвердження за чужим платежем.
Що змінили в перевірці прав
Володіння перенесли в сервісний шар: тепер кожен виклик контуру звіряє суб’єкт сесії з власником операції, а ідентифікатори із запиту більше не вважаються доказом права. Точка авторизації одна й спрацьовує до бізнес-логіки, тому новий обробник не можна додати в обхід перевірки.
Рішення щодо доступу пишуться в аудит-лог із суб’єктом, операцією та результатом — розбір інциденту займає хвилини.
Як вимірювали результат
До правок перевірку власника мали 12 обробників контуру з 40. Після — усі, і це закріплено не звітом, а регрес-набором із 60 сценаріїв обходу: зміна ідентифікатора, чужа сесія, повтор запиту, змінений порядок викликів. Набір проганяється на кожній збірці, тому повернення класу атак ловиться до викочування.
Повторний пентест за тим самим сценарієм знахідок не дав: спроба обходу впирається у відмову до виконання бізнес-логіки й залишається в аудиті. Швидкість розробки при цьому не впала — перевірка володіння стала поведінкою за замовчуванням, а не окремим завданням у кожній доробці.
Що робити, якщо пентест уже проводився, а знахідки не закриті
Повторний пентест не починається з нуля. Спочатку ми звіряємо реєстр минулих знахідок із поточним станом застосунку: відтворюємо вихідний вектор на актуальній копії та фіксуємо, закритий він чи лише замаскований.
Пошук нових уразливостей запускаємо після цього — інакше замовник платить за роботу, яка вже зроблена.
Закритою знахідка вважається лише за відтворенням. Якщо вихідний запит більше не проходить, але з’явився обхідний шлях, статус залишається «відкрита». Тому в кожного рядка у звіті два підтвердження: що саме змінено в коді або конфігурації та чим це перевірено.
| Стан знахідки | Залишковий ризик | Що перевіряємо |
|---|---|---|
| Закрита, є підтвердження | Низький | Вихідний вектор і обхідні шляхи до тієї самої функції |
| Закрита частково | Високий | Сусідні точки входу та альтернативні способи експлуатації |
| Прийнята як усвідомлений ризик | Контрольований | Компенсаційні заходи: фільтрація, журналювання, обмеження доступу |
| Не відтворюється | Невизначений | Повторна спроба на актуальній копії з іншими умовами |
| Хибне спрацювання | Відсутній | Знімаємо з обліку з обґрунтуванням у звіті |
Такий порядок прибирає подвійну оплату за одне й те саме: перевірка знахідок займає лише частину повторного пентесту, а покриття залишається повним. Незакриті уразливості отримують пріоритет за залишковим ризиком, а не за формальною критичністю зі старого звіту.
На виході — реєстр знахідок зі статусами, залишковим ризиком і строком закриття, плюс підтвердження виправлень. Це робочий документ і для розробки, і для наступної перевірки.
Технічні сумніви: запитання інженерів і служби безпеки
До старту ми проводимо технічний дзвінок з інженерами та службою безпеки — на ньому спливають ті самі п’ять запитань. Відповідаємо на них заздалегідь, щоб на момент узгодження рамок не залишилося неясностей: ні щодо навантаження на робочий контур, ні щодо юридичної сторони.
Перевірка покладе робочий контур?
Активні сценарії відпрацьовуємо на копії контуру або в узгодженому вікні, коли навантаження мінімальне. Навантажувальні перевірки обмежуємо часткою від звичайного трафіку, а найризикованіші класи перевіряємо вручну на стенді — без масових запитів до живої системи.
Що робити зі сторонніми компонентами, вихідних кодів яких у нас немає?
Фіксуємо повний список бібліотек і зовнішніх сервісів і за кожним дивимося відомі уразливості та налаштування. Там, де вихідних кодів немає, оцінюємо поведінку за непрямими ознаками та чесно позначаємо сліпі зони окремим розділом звіту.
Як доведете, що уразливість справді експлуатується?
Кожна знахідка підтверджується відтворюваним сценарієм: послідовність кроків, запит і відповідь, запис екрана або фрагмент журналу. Знахідки без підтвердження йдуть у розділ «потребує додаткової перевірки» і не змішуються з підтвердженими.
Це законно — ви будете атакувати нашу систему?
Роботи йдуть лише після письмового дозволу власника систем і строго в узгоджених межах: перелік адрес, вікна часу, заборонені зони. Зовнішні сервіси та чужі майданчики не зачіпаємо, а вихід за рамки — окреме письмове узгодження.
Чи можна зупинити роботи на льоту і що буде з доступами?
Так, у вашої сторони залишається контакт для екстреної зупинки — роботи припиняються негайно. Тестові облікові записи та видані доступи відкликаємо по завершенні, звіт передаємо в закритому вигляді, а маршрут перевірки узгоджуємо заздалегідь.
Обговоримо завдання та межі перевірки
Пентест веб-застосунку починається не із запуску сканера, а з узгодження меж: що входить у перевірку, з якими правами ми працюємо і які сценарії чіпати не можна.
Без цього оцінка виходить або завищеною — «про всяк випадок перевіримо все», або неповною, коли найцікавіший вузол залишається за периметром.
Щоб повернутися з оцінкою та планом робіт, нам потрібні від вас:
- Перелік доменів, службових інтерфейсів і мобільних точок входу в межах перевірки — і явний список того, що залишається ззовні.
- Доступи: тестові облікові записи для кожної ролі, включно з адміністратором, гостьовий вхід і відновлення пароля.
- Обмеження: режимні вікна, заборонені прийоми, тестові платіжні контури замість бойових, допустима інтенсивність запитів.
- Пріоритети: які вузли критичні — вхід у систему, оплата, завантаження файлів, обмін із зовнішніми сервісами.
- Дані: копія бази або масковані набори, щоб перевірка не змінювала реальні записи користувачів.
- Контакти відповідального та чергового інженера на час робіт і порядок зв’язку при критичній знахідці.
- Організаційне: чи потрібно повідомляти провайдера інфраструктури і чи є готовий відкат конфігурації.
У відповідь ви отримуєте план робіт за етапами з вікнами, перелік сценаріїв для перевірки і правила зупинки: якщо знахідка потребує негайного втручання, ми зв’язуємося з черговим, а не продовжуємо в тиші.
Опишіть завдання та межі — повернемося з оцінкою та планом, підготовка до старту займає один короткий дзвінок.
