Інструменти й процес security-тестування

Чим перехоплювальний проксі відрізняється від сканера вразливостей і чому починають саме з нього?

Проксі показує справжній трафік, сканер — лише власну здогадку про нього. Перехоплювальний проксі (intercepting proxy) стає посередником між браузером тестувальника й застосунком: усе, що йде в обидва боки, можна прочитати, затримати, підправити й відпустити далі — саме так ZAP описує свою основу, «manipulator-in-the-middle proxy». Сканування в такому інструменті — не окремий продукт, а один із режимів, і його результат є першим зрізом по очевидному, а не картою застосунку. Практичний наслідок: перш ніж вмикати автоматику, варто просто походити продуктом крізь проксі — тоді видно реальні ендпоінти, заголовки й параметри, зокрема ті, яких у документації API немає. Цей же прохід дає матеріал для всього подальшого: конкретний запит з історії їде в повторне надсилання, у підстановку пейлоадів і в баг-репорт.

Пасивне і активне сканування — у чому різниця і чому вона важлива не лише технічно?

Пасивний режим лише читає, активний — б'є. Пасивна перевірка розбирає повідомлення, які крізь проксі вже пройшли, нічого у відповідях не змінює й тому вважається безпечною; технічно це окремий додаток, що обробляє HTTP- і WebSocket-повідомлення, пропущені або надіслані інструментом. Активна перевірка навпаки застосовує до обраних цілей відомі атаки — це не «перевірка», а справжня атака, і дока ZAP прямо попереджає, що функціональності сайту й даним можлива реальна шкода. Звідси і правовий бік: пасивний прохід можна робити будь-де, куди вам дали доступ, а активний — лише проти цілі, на тестування якої є дозвіл. Ця ж лінія проходить і термінологічно: оцінювання (assessment) виявляє вразливості, не намагаючись їх задіяти, а тестування — виявляє зі спробою експлуатації, тож дозволу потребує саме друге. На співбесіді цінують саме цю межу: кандидат, який каже «я просто прогнав ZAP по стейджу клієнта», щойно розповів, що запускає атаку без мандату.

Що таке SAST і DAST, і чи вистачить у проєкті чогось одного?

SAST (Static Application Security Testing) читає вихідний або зібраний код, DAST (Dynamic Application Security Testing) стукає в запущений застосунок, зазвичай ззовні, як це робив би сторонній. Перший клас зручний тим, що вбудовується в IDE, добре масштабується на нічні збірки й CI і показує адресу дефекту — файл, рядок, іноді сам фрагмент. Другий шукає те, що видно по відповідях: міжсайтовий скриптинг, інʼєкції, path traversal, недбалу конфігурацію сервера. Обійтися одним не вийде, бо в них різний вхід: статичний аналіз не бачить конфігураційних проблем, бо в коді їх немає, а динамічний скан працює ззовні й без доступу до коду — тоді як частину дефектів (той самий path traversal) без доступу до коду не знаходять узагалі. Сильна відповідь додає третє: обидва класи разом усе одно не закривають перевірку — вони знаходять типове й дешеве, а дороге лишається людині. Поруч у переліку кроків пайплайна стоїть ще IAST, але означення йому канон не дає, тож вигадувати його не варто; SCA — вже про склад залежностей, а не про власний код.

Чому питання «це SAST-інструмент чи DAST-інструмент» вважають поставленим неправильно?

Тому що SAST і DAST — назви типів перевірки, а не ярлики на коробках. OWASP у своїх переліках прямо каже, що інструмент туди потрапляє за наявністю відповідних можливостей, і один продукт може вміти кілька типів перевірок одразу. Тобто правильне питання звучить інакше: «яку перевірку ми зараз проганяємо і що подаємо їй на вхід — репозиторій чи піднятий застосунок». Для QA це не термінологічна педантика: коли в релізному чеклисті написано «прогнали інструмент X», незрозуміло, що саме перевірено; коли написано «статичний аналіз коду плюс динамічний скан стейджа» — зрозуміло. І деталь для контексту: у своїх переліках інструментів OWASP тримає абетковий порядок замість рейтингу, нікого з вендорів не радить і публічно відхрещується від чужих порівнянь — тобто «є в списку OWASP» рекомендацією не є.

Які межі має інструментальна перевірка і чому «зелений сканер» не є критерієм готовності релізу?

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

Для чого в Burp Suite потрібні Proxy, Repeater та Intruder?

Це три ланки одного воркфлоу навколо одного запиту. Proxy — вхідна точка: вебпроксі між браузером і застосунком, який перехоплює, показує й дозволяє змінювати трафік в обидва боки, зокрема HTTPS; саме звідти запит передають далі. Repeater — «змінити й надіслати ще раз»: підставити інше значення параметра, пройти багатокроковий процес по кроках, вручну перевірити те, що повідомив сканер; правки лишаються в історії вкладки, тож видно, яка саме зміна дала іншу відповідь. Intruder — та сама механіка, але автоматично: один запит повторюється багато разів, а в заздалегідь позначені позиції підставляються різні пейлоади. Для QA це впізнавана логіка: Repeater — це ручний негативний кейс, Intruder — його параметризований прогін.

Мапа сайту в Burp заповнена. Чи можна вважати це покриттям?

Ні, і плутанина тут коштує дорого. Мапа сайту — накопичувач того, що інструмент зібрав, поки ви ходили застосунком, і в ній є два різні стани: адреса, яку справді запитали, і адреса, яку лише знайшли в посиланні чи скрипті — друга підписана сірим. Сіре в мапі означає «ми знаємо, що воно існує», а не «ми це перевірили». Друга деталь так само важлива: запити показані разом із методом, тож той самий шлях, викликаний GET і PUT, — це два окремі рядки, а не один. Саме в цій різниці зазвичай і живуть дірки в контролі доступу: читання закрили, а запис на той самий ресурс забули. Тому «мапа велика» — не метрика; метрика — перелік ендпоінтів, які реально стукали, у розрізі методу й ролі.

У звіті сканера знахідка «high severity, tentative confidence». Як її читати?

Це дві незалежні осі, і плутати їх — класична помилка тріажу. Серйозність (high, medium, low, informational) каже, наскільки боляче буде, якщо це правда. Впевненість (certain, firm, tentative) каже, наскільки надійною була техніка виявлення: наприклад, для сліпої SQL-інʼєкції висновок робиться за непрямими ознаками, і саме тому інструмент знижує впевненість, а не серйозність. Тобто «high + tentative» читається як «якщо підтвердиться — терміново, але спершу підтвердь». Дока Burp узагалі називає свої оцінки індикативними й вимагає переглядати їх зі знанням функціональності й бізнес-контексту, бо інструмент не знає, що ваш «тестовий» ендпоінт відкритий у проді. Штатна процедура підтвердження проста: узяти той самий запит і повторити його вручну в Repeater, зафіксувавши різницю у відповідях.

Що таке фазинг і де його межа?

Фазинг (fuzzing) — автоматична подача застосунку несподіваного, спотвореного або напівспотвореного вводу заради неочікуваної поведінки. Фазер складається з двох частин: генератора даних і засобів спостереження — і друга половина не менш важлива, бо знайти падіння мало, треба ще побачити й зафіксувати наслідок. Вхід будують двома способами. Перший — готові списки значень, які для конкретного типу даних уже відомі як небезпечні: для чисел це нуль, мінус і величезні значення, для рядків — екрановані послідовності. Другий спосіб бере ті самі кандидати зі специфікації: що вона забороняє, що резервує, які поля повʼязані між собою й де в них ліміти довжини. Мішені у вебі теж перелічені — адреси, форми, будь-який контент від користувача та виклики RPC. Межі названі там же і звучать парадоксально: фазери тяжіють до простих дефектів, і що краще фазер знає протокол, то менше дивних помилок він знайде, бо перестає генерувати те, що протоколом «не буває».

Що таке моделювання загроз і які чотири питання його утворюють?

Моделювання загроз (threat modeling) — структурований і повторюваний процес: побудувати модель системи з погляду безпеки, визначити застосовні до неї загрози й вирішити, що з кожною робити. Дивляться на систему очима супротивника, а не автора. Каркас тримається на чотирьох питаннях: над чим працюємо; що тут здатне піти не так; що ми з цим робимо; і чи вийшло достатньо добре. Перше питання зазвичай закривають діаграмою потоків даних, де мають бути видні межі довіри, потоки, сховища, процеси й зовнішні сутності — саме вони і є кандидатами в точки атаки. На друге відповідають брейнштормом або структурованою технікою (STRIDE, дерева атак, kill chains), а відповідей на саму загрозу є рівно чотири: помʼякшити, усунути, перенести, прийняти. Варто памʼятати, що єдиного галузевого стандарту процесу тут немає, тож «неправильної» реалізації в сенсі відхилення від припису не існує.

Розкажіть про STRIDE.

STRIDE — мнемоніка з шести категорій загроз, придумана в Microsoft, і її призначення суто прикладне: розкласти загрози по коробках, щоб питання до фічі виходили точними. Spoofing питає, чи вдасться комусь прикинутися чужим акаунтом, і б'є по автентифікації. Tampering — чи є спосіб підмінити дані, які лежать у сховищі або їдуть каналом; страждає цілісність. Repudiation перевіряє, чи можна діяти безслідно, тобто потім відхреститися від власної дії (тут канон роздвоюється: одна шпаргалка OWASP ставить у пару облік дій, інша — незаперечність). Information disclosure шукає спосіб дотягтися до чужих даних без права на них, тобто б'є по конфіденційності. Denial of service питає, чи легко відрізати нормальним користувачам доступ до сервісу. Elevation of privilege — чи здатен звичайний акаунт дорости до прав, які йому не належать; це вже про авторизацію. Ключове доповнення, яке відрізняє сильну відповідь: STRIDE не міряє ризик, вона лише каталогізує загрози — пріоритизація йде окремим кроком.

Де в моделюванні загроз місце QA і що з нього виносять у тести?

На останньому кроці, і він описаний цілком формально: готову модель мають переглянути всі стейкхолдери, а контрольні питання до неї звучать по-тестувальницьки — чи піддаються перевірці узгоджені помʼякшення і чи є чим виміряти, виконано вимогу з моделі чи ні. Тобто QA приходить не «послухати архітектуру», а перевірити формулювання на придатність до перевірки: вимога «покращити валідацію» тестом не стає, вимога «сервер відхиляє запит із чужим accountId кодом 403» — стає. Саме тому канон вимагає, щоб помʼякшення були придатними до дії, а не гіпотетичними; звідти ж корисне означення — вразливості це ті загрози, які лишилися без контрзаходу. Друга частина ролі — тригери перезапуску: модель не малюють один раз, її переглядають при новій фічі, інциденті безпеки, змінах архітектури чи інфраструктури. І третя, найпрактичніша: із категорій STRIDE прямо ростуть негативні кейси, тож моделювання для тестувальника є ще й джерелом тест-дизайну.

Що таке поверхня атаки й що змушує її переглянути?

Поверхня атаки (attack surface) — усі точки, якими зловмисник міг би зайти в систему, і всі, якими міг би винести дані назовні; ширше означення додає сюди й самі цінні дані — секрети та ключі, критичні бізнес-дані, персональні дані. Мапують її за готовим переліком: форми й поля інтерфейсу, HTTP-заголовки й cookie, API, файли, бази, інші локальні сховища, пошта й повідомлення, аргументи запуску. Поверх накладають ролі, тримаючи фокус на двох крайностях — анонім і привілейований адміністратор, — а пріоритет віддають віддаленим точкам входу. Точки виходу не менш важливі: без них атака не завершується, бо і міжсайтовий скриптинг, і розкриття інформації потребують каналу назовні. Переглядати поверхню треба, коли міняється керування сесіями, автентифікація чи паролі, а росте вона непомітно: кілька розгорнутих версій, забуті фічі, старі бекапи, невикористовуваний код. Для QA це прямий вплив на скоуп: реліз, який «лише додає фічу», може змінити перелік того, що взагалі треба перевіряти.

Як влаштований пайплайн DevSecOps і що в ньому стоїть найпершим?

У гайдлайні OWASP це не паралельний процес біля розробки, а набір кроків, дописаних до пайплайна, який у команди вже є; мету формулюють через швидкість — побачити проблему якомога раніше, — а саму проблему розкладають на дві половини: дефект дизайну і вразливість застосунку. Порядок такий: нульовим кроком іде моделювання загроз, далі pre-commit (керування секретами, лінт коду), далі стадія сканування (SAST, DAST, IAST, SCA, інфраструктура, контейнери) і аудит відповідності. Дві деталі важать для тестувальника. Перша: нульовий крок стоїть до коду, тобто найдешевша знахідка робиться на дизайні, а не в прогоні. Друга: перший технічний крок — це сканування репозиторію на витік креденшелів, теж до збірки. Вибір інструментів гайдлайн лишає команді, але радить мати одне місце, де всі знахідки зводяться в спільну картину, інакше кожен інструмент живе своїм життям.

Кроки безпеки в пайплайні є. Чи означає це, що пайплайн безпечний, і як міряють зрілість процесу?

Ні, і це три різні питання. Наявність кроків нічого не каже про сам пайплайн: він є привабливою ціллю саме тому, що посідає центральне місце в циклі розробки, а його кроки часто виконуються високопривілейованими ідентичностями — звідси високий потенціал шкоди при компрометації; як приклади наводять випадки Codecov і SolarWinds. Для тестувальника з цього випливають три конкретні речі: дефолтні налаштування вендора безпечними вважати не можна, деплой у прод не пускають без людського апруву й рев'ю, а стовідсоткової точності від алертів чекати не варто, тож розбір шуму треба закласти в процес окремо. Варто памʼятати й системний бік: CI/CD збільшує поверхню атаки організації, і вектором тут є не сама технологія — пайплайн тримається на людях, процесах і технології, і кожна з трьох ланок може стати шляхом атаки. Питання зрілості виносять окремо, у SAMM: це відкритий фреймворк, який допомагає організації сформулювати стратегію безпеки під власні ризики, він не привʼязаний до технології й процесу, будується чіткими ітераціями, а покращення в ньому треба вміти показати — тож фраза «у нас є SAMM» без показаних вимірів не варта нічого.

У чому різниця між ASVS і WSTG? Чи можна написати в критеріях виходу «пройшли по WSTG»?

Це документи з різними ролями: WSTG дає процедуру перевірки, ASVS — перевірні вимоги, проти яких виноситься вердикт. Сам WSTG називає себе повним каркасом тестування, а не простим чеклистом, і пояснює причину: перелік вразливостей поповнюється безперервно, тому вичерпного списку перевірок не складе ніхто. Означення тестування в ньому теж показове — це порівняння стану системи з набором критеріїв, а критерії гайд не видає. Видає їх ASVS, причому у формі, звичній для QA: вимога перевірна, результат — pass або fail, у стандарті є лише обовʼязкові вимоги, тож «зробили частково» станом не є. Рівнів три (L1, L2, L3), і призначає їх не стандарт, а сама організація зі свого профілю ризику. Тому «пройшли по WSTG» критерієм виходу бути не може: це опис виконаної процедури, а не вердикт проти вимог. Дрібниця з того самого ряду: ідентифікатори в обох документах пишуть із версією, бо між редакціями вони змінюються, а OWASP при цьому нікого не сертифікує.

Навіщо піднімати Juice Shop чи DVWA, якщо є стейдж?

Бо активну атаку можна вести тільки проти цілі, на тестування якої є дозвіл, а навчатися треба на чомусь. Juice Shop прикидається невеликим магазином соків, а всередині має завдання різної складності на закладені вразливості; закладали їх свідомо, але відтворювали такими, якими вони бувають у живих проєктах, і прогрес застосунок рахує сам. Дві його властивості визначають спосіб роботи: один інстанс розрахований на одного користувача, а самовідновлення на старті сервера стирає базу й теку, яку могли змінити під час зламу, — тож докази (скріншоти, запити, HAR) збирають одразу, інакше після падіння їх не буде. Падіння під агресивним прогоном там штатне і знахідкою не рахується. DVWA — навмисно вразливий застосунок на PHP і MariaDB з рівнями складності, які задають конфігурацією; головне правило запуску найсуворіше з усіх: його не можна класти в публічну теку хостингу чи на сервер, доступний з інтернету, — рекомендують віртуальну машину в режимі NAT. Корисна деталь для тих, хто ганяє сканери: у DVWA є опція вимкнути перевірку автентифікації, бо частина інструментів із логіном не працює.

Ви прогнали DAST по стейджу, і в моніторингу тиша. Що це означає?

Що ви щойно знайшли дефект, тільки не той, який шукали. Категорія A09:2025 про збої логування й сповіщень формулює це як прямий тест: якщо прогін DAST-інструмента або пентест не породжує жодного сповіщення, це і є дефект. Тобто прогін працює у два боки: шукає вразливості й одночасно зʼясовує, чи помічає система напад на себе. Поруч перевіряють суміжні ознаки: чи логуються всі події, які підлягають аудиту (класика — успішні входи пишуться, невдалі ні), чи захищена цілісність логів від підміни, чи не течуть у лог персональні дані, чи екрануються дані події перед записом — інакше в саму систему логування можна впорснути свій рядок через CR і LF. Розраховувати тут на сканер не варто: категорію називають надзвичайно важкою для тестування, і в даних CVE вона представлена мінімально, тож перевіряють її руками й домовленістю з тими, хто дивиться на алерти.

Ви знайшли вразливість у чужому сервісі. Ваші дії?

Спочатку зупинитися й перевірити, чи саме тестування було легальним і дозволеним, — це перший обовʼязок того, хто знайшов. Далі — знайти канал: докласти розумних зусиль, щоб звʼязатися з командою безпеки, зокрема подивитися /.well-known/security.txt, де організація могла описати спосіб звʼязку. У звіті має бути стільки конкретики, щоб чужа команда відтворила знахідку без вашої участі й переконалася в ній сама, — інакше це не звіт, а натяк. Чого робити не можна: вимагати оплату чи винагороду поза наявною програмою — це може бути кваліфіковано як вимагання, як і плата за непублікацію. Далі працює модель розкриття: типово приватна, коли рішення про публікацію належить організації; відповідальна (координована), коли повні деталі виходять після патча і процес рухає дедлайн; повна — крайній засіб. І юридична межа, про яку забувають: safe harbor прикриває дослідника рівно доти, доки той не вийшов за scope і правила програми; крок за цю межу вже може тягнути на кримінальну відповідальність.

Що таке security.txt і чи дає він дозвіл на тестування?

Це описаний RFC 9116 текстовий файл, який машинно розбирається й каже, як організація приймає повідомлення про вразливості. Нормативний мінімум перевіряється за кілька хвилин: файл лежить під /.well-known/ (копію в корені лишили тільки заради сумісності, і за наявності обох чинною є та, що під /.well-known/), віддається по https з типом text/plain і charset=utf-8, обовʼязково має поле Contact (значення бажано в порядку переваги) і рівно одне поле Expires, дату в якому рекомендують ставити менше ніж на рік уперед. Область дії — рівно той домен або IP, з URI якого файл узято: ні піддомени, ні батьківський домен він не покриває. Дозволу на тестування файл не дає: ані з його наявності, ані з його відсутності не можна виснувати ані дозвіл, ані заборону — дозвіл дає політика розкриття. Крім того, він не рятує від захопленого сайту (зламавши сайт, атакувальник підмінить і цей файл або поставить редирект на себе), а протухлий файл RFC прямо називає гіршим за відсутній.

Три ситуації, у яких теорія цієї глави перетворюється на роботу: розбір звіту сканера за двома шкалами й перетворення підтвердженої знахідки на регресійний тест, сорокахвилинна STRIDE-сесія над однією фічею з таблицею «питання → перевірка», і домовленість перед прогоном — окремо для своєї цілі й окремо для чужої.

Кейс 1. Звіт сканера на 47 алертів: із чого починати тріаж

Нічний прогін сканера по стейджу приніс 47 записів. Читати їх зверху вниз — найгірша стратегія: у звіті дві незалежні шкали, і саме їхня пара каже, що робити першим.

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

Штатний спосіб підтвердити знахідку — узяти той самий запит із історії проксі й повторити його вручну, змінюючи по одному параметру:

POST /api/reports/export HTTP/1.1
Host: staging.example.com
Content-Type: application/json
Cookie: sid=...

{"reportId": 8123, "format": "pdf"}

Повторюємо з "reportId": 8124 (чужий звіт), потім з "format": "../../etc/passwd", потім тим самим тілом, але методом PUT. Останнє — не формальність: у мапі сайту GET /api/reports/export і PUT /api/reports/export є двома різними рядками, і контроль доступу на них теж різний.

Що йде в тікет, а що ні:

Підтверджену знахідку закріплюють тестом, інакше вона повернеться наступним релізом:

import { test, expect } from '@playwright/test';

// Регресія на підтверджену знахідку: помилка не має віддавати внутрішні деталі
test('кривий payload дає 400 без стек-трейсу', async ({ request }) => {
  const res = await request.post(`${process.env.BASE_URL}/api/reports/export`, {
    headers: { 'content-type': 'application/json' },
    data: '{"reportId": "не-число"',
  });

  expect(res.status()).toBe(400);

  const body = (await res.text()).toLowerCase();
  expect(body).not.toContain('sqlstate');
  expect(body).not.toContain('stack');
  expect(body).not.toMatch(/\/(usr|home|var)\//);
});

Що дивитися і чому:

• Асерт на код і на тіло окремо. Правильний 400 із повним стек-трейсом у тілі — це все ще знахідка: категорія розкриття даних живе саме в тілах помилок.
• Порожній звіт неоднозначний. «Сканер нічого не знайшов» і «сканер не достукався до застосунку» виглядають однаково, тому в описі прогону фіксують інструмент, версію, ціль і кількість запитів.
• Прогін наступним інструментом дасть інші числа — і це нормально. Тести в сканерах не стандартизовані, тож порівнювати можна лише прогін із прогоном того самого інструмента.

Кейс 2. STRIDE над однією фічею за сорок хвилин

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

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

Що дивитися і чому:

• STRIDE не міряє ризик. Вона лише розкладає загрози по категоріях, щоб питання були точними; пріоритизація йде окремим кроком, і тут канон OWASP сам собі суперечить — один документ радить добуток імовірності на вплив, інший навпаки радить якісні оцінки, щоб не плодити псевдоточність.
• Місце QA — на кроці валідації. Перевірочні питання сформульовані по-тестувальницьки: чи можна протестувати узгоджені помʼякшення і чи можна виміряти успіх або невдачу вимоги. Ліва колонка таблиці на це «ні», права — «так».
• Модель не малюють один раз. Тригери перезапуску названі: нова фіча, інцидент, зміни архітектури чи інфраструктури. Поверхню атаки перезапускає ще й вужчий набір — зміни в автентифікації, сесіях і керуванні паролями.

Кейс 3. Перед прогоном: чия це ціль

Найдорожча помилка в цій темі коштує не флаку, а роботи. Питання «чия ціль» ставлять до того, як натиснути кнопку.

Своя ціль (стейдж вашого продукту). Пасивний прохід крізь проксі можна робити одразу — він нічого не змінює. Для активного скану домовляються заздалегідь:

• письмовий дозвіл власника системи, а не «ну ми ж усі свої в одному чаті»;
• вікно прогону й попередження всім, хто побачить сплеск: SRE, хостинг, CDN;
• свіжий бекап цілі — активна перевірка справді може зіпсувати дані;
• зафіксовані інструмент, версія, перелік цілей і час старту й кінця;
• моніторинг не вимикають — це друга половина перевірки.

Остання умова і є найцікавішою. Прогін дає два результати, а не один:

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

Окремо про навчальні стенди. Юридично вони існують саме для того, щоб було де бити на повну, але поводяться специфічно: агресивний прогін кладе Juice Shop штатно, а самовідновлення на старті сервера стирає базу й теку, яку могли змінити під час зламу. Тому докази збирають одразу — скріншот, HAR, збережений запит, — інакше після перезапуску доводити буде нічим. Падіння стенда під сканером знахідкою не рахується. DVWA має жорсткіше правило: його не кладуть у публічну теку хостингу й не виставляють у мережу, рекомендований спосіб — віртуальна машина в режимі NAT.

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

# канонічне місце за RFC 9116 (копія в корені допускається лише для сумісності)
curl -sSI https://partner.example.com/.well-known/security.txt

# сам вміст: Contact і Expires читаємо очима
curl -sS https://partner.example.com/.well-known/security.txt

Що саме дивитися у відповіді:

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

Що дивитися і чому:

• Наявність файла дозволу не дає. Ані з присутності, ані з відсутності security.txt не випливає ні дозвіл, ні заборона: тестування легалізує політика розкриття, а safe harbor діє лише всередині scope і правил програми.
• Протухлий файл гірший за відсутній — так це сформульовано в самому RFC. Дата в Expires у минулому означає, що адреса в Contact могла давно померти разом із командою, яка її читала.
• Зламаний сайт підмінить і цей файл. Атакувальник, який дістав контроль, може поставити свою адресу або редирект на себе, тож канал із security.txt — зручність, а не гарантія.

Каркас: критерій проти процедури

• Знаю різницю між WSTG і ASVS: перший дає процедуру перевірки й сам відмовляється бути чеклистом, другий дає перевірні вимоги з вердиктом pass або fail — тому «пройшли по WSTG» описує виконану роботу, а критерієм виходу не є.
• Памʼятаю дрібниці ASVS: у стандарті лише обовʼязкові вимоги (тож «частково виконали» станом не є), рівні L1–L3 призначає організація зі свого профілю ризику, ідентифікатори пишуть із версією, а OWASP при цьому нікого не сертифікує.
• Розумію, що обʼєктом перевірки є люди, процес і технологія, найощадніше місце знахідки — дизайн, а жодна окрема техніка (інспекція, моделювання загроз, рев'ю коду, пентест) не самодостатня; сам процес узгоджують із процесом розробки й міряють проти критеріїв виходу.

Проксі й тріаж знахідки

• Можу пояснити, чому починають із перехоплювального проксі, а не зі сканера, і памʼятаю сліпу зону пасивного проходу: сторінки за формою входу не виявляються, доки не налаштована автентифікація.
• Знаю різницю між пасивним і активним скануванням і те, що межа тут не технічна, а про мандат; сюди ж лягає пара «оцінювання проти тестування» — дозволу потребує саме спроба експлуатації, а оцінка ризиків тестом не є взагалі. Умови активного прогону теж можу назвати: вивчений інструмент, резервна копія цілі, авторизація власника, прийнятий обома сторонами ризик пошкодження.
• Розрізняю ролі в наборі (Proxy як вхідна точка, Repeater як повторне надсилання зміненого запиту, Intruder як підстановка пейлоадів у позначені позиції) і не читаю мапу сайту як покриття: сірий підпис означає «знайдено, але не запитано», а той самий шлях із GET і з PUT — два окремі рядки.
• Розрізняю серйозність і впевненість як дві незалежні шкали знахідки, памʼятаю, що ненадійна техніка виявлення знижує саме впевненість, і підтверджую знахідку повторним ручним запитом, бо оцінки інструмента індикативні.

Класи перевірок і їхні межі

• Знаю різницю SAST vs DAST за входом перевірки (вихідний або зібраний код проти запущеного застосунку ззовні) і розумію, чому клас описує перевірку, а не продукт: один інструмент може вміти кілька типів.
• Можу перелічити межі статичного аналізу: погана автоматизація автентифікації, контролю доступу й криптографії, малий відсоток виявлених дефектів, багато хибнопозитивних, невидима конфігурація й складність довести реальність знахідки.
• Розумію межу класу як такого: інструмент не робить софт захищеним, а прогін корисний насамперед як перший прохід по очевидному; тому й звіти двох сканерів не взаємозамінні — тести не стандартизовані, і розбіжність не є дефектом жодного з них.
• Можу пояснити фазинг як техніку: подача несподіваного або спотвореного вводу, дві частини фазера (генератор даних і засоби спостереження), два способи будувати вектори (списки небезпечних значень під тип або сама специфікація) і межа — тяжіння до простих дефектів.

Моделювання загроз і поверхня атаки

• Знаю чотири питання каркаса (над чим працюємо, що може піти не так, що зробимо, чи достатньо добре) і чотири відповіді на загрозу: помʼякшити, усунути, перенести, прийняти.
• Можу розгорнути STRIDE у шість питань до конкретної фічі, назвати властивість, яку порушує кожна категорія, і памʼятаю, що сама мнемоніка ризик не міряє.
• Розумію роль QA на кроці валідації: помʼякшення має бути придатним до дії й перевірним, модель рецензують усі стейкхолдери, а перезапускають її за подіями — нова фіча, інцидент, зміни архітектури чи інфраструктури.
• Можу перелічити точки поверхні атаки (форми й поля, заголовки й cookie, API, файли, бази, локальні сховища, повідомлення, аргументи запуску), пояснити, навіщо окремо рахують точки виходу, і назвати тригер перегляду — зміни в автентифікації, сесіях і керуванні паролями.

Пайплайн, зрілість і стенди

• Знаю порядок кроків DevSecOps (моделювання загроз нульовим, до коду → пошук креденшелів у репозиторії й лінт → сканування → аудит відповідності) і розумію, що ці кроки не роблять безпечним сам пайплайн: він є привабливою ціллю через високопривілейовані ідентичності, тож потрібні ручний апрув перед продом і недовіра до дефолтів вендора, а зрілість процесу — уже окреме питання (SAMM).
• Знаю, навіщо піднімають вразливий стенд, і головні правила: DVWA не виставляти в інтернет (віртуальна машина в режимі NAT), а в Juice Shop памʼятати про один інстанс на користувача, самовідновлення зі стиранням бази на старті й штатне падіння під агресивним прогоном.

Виявлення й розкриття

• Знаю, що прогін DAST або пентест, який не породив жодного сповіщення, сам є дефектом категорії A09, і що цю категорію називають надзвичайно важкою для тестування, а в даних CVE вона представлена мінімально.
• Можу назвати обовʼязки обох сторін розкриття, розрізняю приватну, повну й відповідальну моделі, памʼятаю про дедлайн як рушій третьої та про межу safe harbor: він діє лише в межах scope і правил, а вимога оплати за інформацію чи за непублікацію може становити вимагання.
• Можу за пʼять хвилин перевірити security.txt на відповідність RFC 9116 (розташування під /.well-known/, схема https, тип text/plain, обовʼязковий Contact і рівно один Expires, область дії рівно того домену, звідки файл узято) і назвати три речі, яких він не робить: не дає дозволу на тестування, не рятує від підміни на захопленому сайті, а протухлим стає гіршим за відсутній.