Black box, grey box чи white box: який пентест обрати?

Для більшості бізнес-застосунків найбільше знахідок на день роботи дає grey box: пентестери отримують акаунти для кожної ролі і частину документації. Black box показує лише те, що бачить сторонній, а white box додає вихідний код і архітектуру і підходить для критичного коду: платежів, входу, прав доступу.

Нижче три формати простими словами з визначеннями NIST і OWASP, порівняльна таблиця, що підготувати для grey box і коли потрібен white box.

Коротко

• Black box (чорна скринька). Пентестер знає лише адресу сайту чи діапазон IP. Він бачить те саме, що сторонній зловмисник.
• Grey box, або gray box (сіра скринька). Пентестер має тестові акаунти для кожної ролі і частину документації, наприклад опис API. Так перевіряють, що може зробити клієнт, партнер чи співробітник.
• White box (біла скринька). Пентестер має вихідний код, опис архітектури і зв'язок з розробниками. Це найглибша перевірка.
• Black box витрачає частину оплачених днів на розвідку і часто не доходить до функцій за логіном.
• Для веб-застосунків, API і мобільних застосунків починайте з пентесту у форматі grey box. White box додайте для коду, де помилка коштує грошей.

Три формати простими словами

Ці назви описують, скільки пентестер знає про систему на старті. Глосарій NIST визначає їх саме через рівень знань:

• black box означає методику, яка не передбачає жодних знань про внутрішню будову і реалізацію об'єкта перевірки ^[1];
• grey box означає методику, яка передбачає деякі знання про внутрішню будову ^[2];
• white box означає методику, яка передбачає явні й суттєві знання про внутрішню будову і реалізацію ^[3].

OWASP Web Security Testing Guide пише, що пентест часто називають black box тестуванням, і тут же додає: у багатьох випадках тестувальник отримує один або кілька робочих акаунтів у системі ^[5]. Тобто на практиці більшість пентестів застосунків уже grey box. NIST SP 800-115 описує grey box як поєднання прийомів white box (аналіз коду) і black box (перевірка працюючого застосунку без знання коду) ^[4].

«Grey» і «gray» означають одне й те саме: перше написання британське, друге американське.

Простіше кажучи: у black box ви даєте пентестеру адресу будинку. У grey box даєте ще й ключі від звичайних квартир. У white box додаєте креслення будинку і схему проводки.

Порівняння: що отримують тестувальники і що ви дізнаєтесь

Чому black box часто дає менше за ті самі гроші

Пентест обмежений днями. Британський NCSC прямо пише: коли тестувальникам не дають інформації, частина вразливостей може лишитися незнайденою за відведений час ^[6]. У black box пентестер витрачає дні на те, що ви могли б розповісти за одну розмову: які є ролі, де API, на чому зроблено систему.

Друга причина важливіша. Без акаунтів пентестер бачить сторінку входу, реєстрацію і публічні сторінки. А найцінніше в бізнес-застосунку стоїть за логіном: особистий кабінет, платежі, адмінка, API мобільного застосунку. Серйозні проблеми часто саме там: клієнт бачить чужі рахунки, звичайний користувач виконує дії адміністратора. Щоб це перевірити, потрібні щонайменше два акаунти однієї ролі і акаунти різних ролей.

Аргумент «black box реалістичніший» працює гірше, ніж здається. Справжній зловмисник не обмежений п'ятьма днями. Якщо у вас відкрита реєстрація, акаунт користувача він отримає за хвилину. Пароль співробітника він може вкрасти фішингом. Grey box одразу починає з цієї точки.

Black box потрібен, коли питання саме таке: що бачить сторонній. Наприклад, після змін в інфраструктурі або для перевірки зовнішнього периметра.

Що підготувати для grey box

Чим краще підготовка, тим більше часу пентестер витрачає на пошук вразливостей, а не на здогадки:

• Тестові акаунти для кожної ролі, по два на роль: клієнт, менеджер, адміністратор, партнер. Два акаунти однієї ролі потрібні, щоб перевірити доступ до чужих даних.
• Тестові дані. Замовлення, рахунки, документи в кожному акаунті. Порожній кабінет нічого не покаже.
• Опис API. Специфікація OpenAPI (Swagger), колекція Postman або хоча б список ендпоінтів.
• Середовище. Staging, максимально схожий на прод, або прод з погодженими обмеженнями. Різницю між ними і що обрати пояснюємо в статті як підготуватися до пентесту.
• Контактна особа на час тесту і спосіб швидко зупинити перевірку.

Що саме перевіряють у веб-застосунку і API, описано в статті як перевірити безпеку сайту і API. Для мобільних застосунків додайте збірки для iOS і Android, деталі в статті пентест мобільного застосунку.

Коли потрібен white box

NIST SP 800-115 зазначає, що для власних застосунків white box зазвичай ефективніше і дешевше знаходить дефекти безпеки, ніж black box. Але він не бачить проблем у взаємодії компонентів і помилок, що з'являються під час збирання і налаштування ^[4]. OWASP додає ще одне обмеження: код, розгорнутий на сервері, може відрізнятися від того, який переглянули ^[5]. Тому white box поєднують з перевіркою працюючої системи.

White box потрібен, коли помилка в коді коштує грошей або доступу:

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

White box не означає перегляд усього коду. Часто достатньо глибоко перевірити критичні модулі, а решту системи протестувати як grey box. Як це виглядає для платіжних сервісів, пояснюємо в статті тестування безпеки фінтеху і платежів.

Зовнішній і внутрішній пентест: інший поділ

Black, grey і white box описують, скільки пентестер знає. Зовнішній і внутрішній пентест описують, звідки він атакує.

За NIST SP 800-115, зовнішнє тестування ведуть ззовні периметра, зазвичай з інтернету. Внутрішнє ведуть з внутрішньої мережі, від імені довіреного співробітника або зловмисника, який уже пройшов периметр. Для внутрішнього тесту пентестеру часто дають доступ рівня звичайного користувача. Якщо потрібні обидва, зовнішній зазвичай роблять першим, щоб пентестер не знав внутрішніх деталей, яких немає у стороннього ^[4].

Ці поділи поєднуються. Наприклад, зовнішній периметр перевіряють як black box, а внутрішню мережу як grey box з акаунтом звичайного співробітника. Про внутрішній тест детально в статті пентест внутрішньої мережі і Active Directory.

Правило вибору

Обирайте black box, якщо:

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

Обирайте grey box, якщо:

• у вас веб-застосунок, API, мобільний застосунок чи SaaS з кількома ролями;
• це перший пентест продукту;
• клієнт або партнер просить звіт про перевірку продукту.

Обирайте white box, якщо:

• через систему проходять гроші або вона керує доступом;
• у вас власна криптографія чи складна логіка прав;
• grey box уже робили, знахідки закриті, і потрібна глибша перевірка.

Якщо пентест для вас новий, почніть зі статті що таке пентест. Формати й межі робіт описані на сторінці пентесту.

Типові помилки

• Обрати black box, бо «так реалістичніше». Оплачені дні йдуть на розвідку, а функції за логіном лишаються неперевіреними.
• Дати один акаунт. З одним акаунтом не перевірити, чи бачить клієнт чужі дані і чи може менеджер зробити дії адміністратора.
• Тестувати на порожньому staging. Без даних немає чого «красти», і частина знахідок не проявиться.
• Дати код без доступу до працюючої системи. Помилки конфігурації і взаємодії компонентів видно лише на живому середовищі.
• Приховати відомі проблеми. NCSC радить передати тестувальникам свіжі результати сканування вразливостей, якщо вони є ^[6]. Тоді пентестер не витрачає час на вже відоме.
• Плутати «grey box» і «внутрішній пентест». Перше про те, що знає пентестер, друге про те, звідки він атакує.

Чекліст: що дати пентестеру для grey box

• Список ролей у системі і по два тестові акаунти на кожну роль.
• Тестові дані в кожному акаунті: замовлення, рахунки, документи.
• Опис API: OpenAPI (Swagger), колекція Postman або список ендпоінтів.
• Адреси середовища і письмове рішення: staging чи прод.
• Короткий опис архітектури: які сервіси, де зберігаються дані, які сторонні інтеграції.
• Збірки мобільних застосунків, якщо вони входять у межі.
• Список заборонених дій і систем поза межами.
• Контакт, доступний під час тесту, і спосіб зупинити перевірку.
• Результати попередніх сканувань і пентестів.

Завантажити чекліст підготовки (PDF)PDF · A4

FAQ

Який тип пентесту найкращий?

Для більшості веб-застосунків, API і мобільних застосунків найкраще працює grey box: пентестер отримує акаунти й документацію і витрачає час на пошук вразливостей. Black box обирають для зовнішнього периметра, white box для критичного коду.

Чи black box реалістичніший за grey box?

Він ближчий до стороннього зловмисника, але той не обмежений кількома днями і часто отримує акаунт через реєстрацію чи фішинг. Grey box починає з цієї точки і встигає перевірити більше.

Чи безпечно давати пентестеру вихідний код?

Так, якщо доступ обмежений межами робіт і NDA, а після проєкту код видаляють. Часто достатньо дати лише критичні модулі, а не весь репозиторій.

Скільки тестових акаунтів потрібно для grey box?

Зазвичай по два на кожну роль. Два акаунти однієї ролі показують, чи бачить користувач чужі дані, а акаунти різних ролей показують, чи можна підвищити права.

Чи можна поєднати кілька форматів в одному проєкті?

Так, і це часта схема. Наприклад, застосунок перевіряють як grey box, платіжний модуль як white box, а зовнішній периметр як black box.

Посилання

1. NIST CSRC Glossary: Black Box Testing csrc.nist.gov
2. NIST CSRC Glossary: Gray Box Testing csrc.nist.gov
3. NIST CSRC Glossary: White Box Testing csrc.nist.gov
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. OWASP Web Security Testing Guide v4.2: Introduction wstg.owasp.org
6. NCSC: Penetration testing ncsc.gov.uk