Як ми тестуємо: наша методологія тестування на проникнення

Ручний підхід, бо сканер бачить лише половину картини

Сканер чудовий у широті охоплення: він визначає ПЗ, відзначає відсутні заголовки й зіставляє відомі сигнатури CVE в тисячах запитів. Але він слабкий у судженні. Він не збагне, що `200 OK`, який повертає рахунок іншого орендаря, — це критична вразливість порушення контролю доступу, адже синтаксично все виглядає правильно. Зловживання бізнес-логікою, межі авторизації, ланцюги вразливостей низької значущості й стани гонитви лежать саме в тій сліпій зоні, про яку автомат не здатен міркувати.

Автоматизацію ми застосовуємо свідомо — Burp Suite Professional, nuclei й точкові скрипти — як підсилювач охоплення й контролю регресій, але ніколи як сам тест. Саме фахівець висуває гіпотези, змінює стан застосунку й підтверджує реальний вплив. У цьому різниця між «інструмент повідомив про це» і «ми це довели».

• Сканери знаходять відомі шаблони; людина знаходить логіку, яка шаблоном ніколи не була.
• Авторизація, мультиорендність і зловживання процесами практично невидимі для сигнатурних інструментів.
• Автоматизація дає охоплення й швидкість; ручне тестування дає доказ і контекст.

Фаза 1 — Підготовка: обсяг, авторизація, правила проведення

Жоден пакет не надсилається до наявності підписаної авторизації. На цьому етапі ми узгоджуємо точний обсяг (хости, домени, застосунки та API в обсязі, а також явні винятки), вікно тестування, рівні облікових записів, під якими тестуємо, і контакти для ескалації. Правила проведення (Rules of Engagement) фіксуємо письмово: що дозволено, що під забороною (наприклад, без атак типу «відмова в обслуговуванні» й без руйнівних навантажень на бойових даних), вихідні IP для додавання до списку дозволених і аварійний канал на випадок підозри на реальну компрометацію чи вкрай крихку систему.

Мету ми формулюємо мовою клієнта — захист персональних даних, запобігання захопленню облікових записів, виконання вимоги ISO 27001 чи SOC 2 — щоб зусилля йшли туди, де справді лежить бізнес-ризик, а не рівномірно розмазувалися по шуму.

• Підписана авторизація й письмово зафіксований обсяг до генерації будь-якого трафіку.
• Правила проведення: дозволені техніки, винятки, години тестування, порядок сповіщення.
• Поіменні аварійні контакти й умова зупинки робіт за ситуації високого ризику.

Фаза 2 — Розвідка й картування

Перш ніж зондувати поверхню атаки, ми будуємо її повну картину. За пасивною розвідкою (DNS, журнали Certificate Transparency, публічний код і метадані) настає активне картування: перелічення хостів, портів і сервісів, обхід застосунку й каталогізація кожної кінцевої точки, параметра, потоку автентифікації та ролі. Це відповідає OWASP WSTG у розділах Information Gathering (WSTG-INFO) і Configuration Management (WSTG-CONF).

Результат цієї фази — внутрішня карта: що чому довіряє, де дані перетинають межу і які кінцеві точки обробляють чутливі об’єкти. Тест, який ви не додумалися провести, — це вразливість, яку ви ніколи не знайдете, тому охоплення поверхні ми вважаємо повноцінним показником якості.

Фаза 3 — Моделювання загроз

Маючи карту, ми міркуємо як атакувальник із цілями. Ми виявляємо значущі активи, межі довіри навколо них і реалістичних суб’єктів загроз — неавтентифікованого користувача з інтернету, клієнта з низькими привілеями, зловмисного інсайдера. Ми перелічуємо сценарії зловживань за кожним компонентом (у стилі STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) і ранжуємо їх за ймовірністю та бізнес-впливом.

Із цього народжується пріоритизований план тестування. Замість того щоб усе перевіряти поверхово, максимум ручних зусиль ми спрямовуємо туди, де успішна атака завдає найбільшої шкоди — платіжні потоки, автентифікація, доступ до даних у мультиорендному середовищі та адміністративні функції.

Фаза 4 — Ручне тестування й безпечна експлуатація

Це ядро роботи. Ми виконуємо план за тест-кейсами OWASP WSTG і категоріями OWASP Top 10, вручну перевіряючи кожну потенційну проблему. Автентифікація й керування сесіями (WSTG-ATHN, WSTG-SESS), авторизація та IDOR/BOLA (WSTG-ATHZ), обробка вводу — injection, SQLi, XSS — (WSTG-INPV), бізнес-логіка (WSTG-BUSL) і криптографія (WSTG-CRYP) охоплюються системно й співвідносяться з контролями ASVS там, де корисний погляд на зрілість.

Експлуатація завжди безпечна й співмірна. Вразливість ми доводимо мінімальною дією, потрібною для її демонстрації: читанням одного запису, до якого не повинні мати доступ, отриманням безневинного токена-доказу, показом контрольованого `alert(document.domain)` для XSS. Ми ніколи не вивантажуємо реальні дані клієнтів, не запускаємо руйнівні навантаження й не знижуємо доступність. Кожен крок логується із запитами й відповідями та мітками часу, щоб знахідку можна було повністю відтворити.

• Системне охоплення категорій OWASP WSTG і OWASP Top 10.
• Доказ впливу найменш інвазивною дією — без крадіжки даних і руйнувань.
• Повні докази запит/відповідь для побайтового відтворення.

Фаза 5 — Після експлуатації: вимірювання реального впливу

Здобуття плацдарму — це ще не знахідка; знахідка — це те, що цей плацдарм означає. Контрольовано й суворо в межах Rules of Engagement ми оцінюємо, як далеко насправді сягає підтверджена вразливість: які дані стають читабельними, чи можна підвищити привілеї, чи складається одна слабкість у ланцюг з іншою й чи веде до найціннішого активу. Відбитий XSS — це одне; відбитий XSS, який краде сесію адміністратора й дозволяє захопити орендаря цілком, — це вже інша розмова для бізнесу.

Ми визначаємо радіус ураження, ніколи не реалізуючи його руйнівно. Підсумок — опис впливу простою мовою бізнесу: «неавтентифікований атакувальник міг перелічити й прочитати рахунки кожного клієнта» — який здатен зважити й нетехнічний керівник.

Фаза 6 — Оцінка ризику за CVSS v3.1

Кожна знахідка отримує базову оцінку CVSS v3.1 й повний векторний рядок, тому оцінка прозора й незалежно перевірювана, а не є суб’єктивним ярликом. Ми оцінюємо Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope і вплив на Confidentiality/Integrity/Availability, а де доречно — додаємо метрики Temporal і Environmental, щоб відобразити реальний контекст клієнта.

CVSS — це відправна точка, а не вся історія. Числову значущість ми співвідносимо з реальним бізнес-впливом і експлуатовністю, тому технічно «середня» проблема, що дає захоплення облікового запису, підвищується в описі й пріоритизується відповідно. Звіт ранжує проблеми так, щоб зусилля з усунення йшли за реальним ризиком.

Ілюстративний приклад знахідки — IDOR в API рахунків

Нижче — ілюстративний приклад, що показує, як ми документуємо знахідку. Це не реальний клієнт і не описує жодну реальну систему.

Назва: Insecure Direct Object Reference (IDOR), що розкриває рахунки між орендарями. Значущість: Висока — CVSS v3.1 8.1 (вектор AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Категорія: OWASP Top 10 A01:2021 Broken Access Control; WSTG-ATHZ-04 (Insecure Direct Object References).

Що ми знайшли: кінцева точка `GET /api/v2/invoices/{id}` повертала об’єкти рахунків за послідовним цілочисловим ідентифікатором і авторизувала запит лише за наявністю чинної сесії, ніколи не перевіряючи, чи належить рахунок орендарю того, хто викликає. Автентифікувавшись як користувач із низькими привілеями в Орендарі A, ми змінили `{id}` з власного `50432` на `50431` і отримали рахунок іншої організації — ім’я клієнта, платіжну адресу, позиції та суму. Інкремент ідентифікатора дозволяв пройти всю таблицю.

Бізнес-вплив: будь-який автентифікований клієнт міг перелічити й прочитати всі рахунки по всіх орендарях — масове порушення конфіденційності персональних і комерційних даних із явним ризиком за GDPR та договірними й репутаційними наслідками.

Усунення: забезпечити авторизацію на рівні об’єкта на сервері для кожного запиту — перевіряти, що `tenant_id` запитаного рахунку збігається з орендарем автентифікованого суб’єкта перед поверненням, і повертати `404` (а не `403`), щоб не підтверджувати існування ресурсу. Замінити послідовні цілочислові ідентифікатори невгадуваними UUID як ешелонований захист і додати автоматичний тест контролю доступу до конвеєра CI, щоб регресія не могла тихо повернутися.

• Значущість: Висока — CVSS v3.1 8.1, вектор AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.
• Першопричина: автентифікація є, авторизація на рівні об’єкта відсутня.
• Усунення: серверна перевірка належності орендарю + UUID + регресійний тест контролю доступу в CI.

Фаза 7 — Звітність, повторний тест і забезпечення якості

Звіт — це продукт. Він відкривається стислим резюме для керівництва, за яким ідуть технічні знахідки — кожна з оцінкою й вектором CVSS, кроками відтворення, доказами з мітками часу, бізнес-впливом і конкретною рекомендацією щодо усунення — не «пропатчте це», а конкретний контроль для впровадження. Знахідки ранжовані так, щоб перше виправлення знімало найбільший ризик.

Якість забезпечується до передавання: кожну знахідку перевіряє другий фахівець, незалежно її відтворюючи, — так ми тримаємо кількість хибних спрацювань близькою до нуля, адже ми не повідомляємо про те, чого не можемо довести. Після усунення ми проводимо безкоштовний повторний тест, підтверджуючи, що кожне виправлення справді закриває проблему й не вносить регресію, і перевидаємо звіт з оновленим статусом. Усе супроводжується NDA; докази й дані клієнта шифруються в стані спокою, доступ до них контролюється, вони зберігаються лише узгоджений строк і безпечно знищуються за графіком.

• Перевірка другим фахівцем із незалежним відтворенням — кількість хибних спрацювань близька до нуля.
• Конкретні, ранжовані рекомендації щодо усунення замість загальних порад.
• Безкоштовний повторний тест після виправлень; NDA, шифрування й планове знищення даних на всіх етапах.

Часті запитання