ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9670| Title: | Програмний комплекс тестування web-ресурсів на вразливість |
| Authors: | Немченко, Вадим В'ячеславович Уваєв, Богдан Сергійович |
| Keywords: | тестування на вразливість;пентестинг;веб-безпека;автоматизоване сканування;python;субдомени;CVE;звітність;інформаційна безпека;vulnerability testing;penetration testing;web security;automated scanning;python;subdomains;CVE;reporting;information security |
| Issue Date: | 17-Jun-2026 |
| Abstract: | АНОТАЦІЯ
Виконавець: Уваєв Богдан Сергійович.
Назва кваліфікаційної бакалаврської роботи: "Програмний комплекс автоматизованого тестування web-ресурсів на вразливість".
Спеціальність: 121 «Інженерія програмного забезпечення».
Установа: Черкаський державний технологічний університет (ЧДТУ).
Місто, рік: Черкаси, 2026 рік.
Основні ідеї: розробка програмного комплексу для автоматизованого тестування web-ресурсів на вразливість із графічним інтерфейсом на базі PyQt6; об'єднання інструментів інформаційної безпеки в єдиний конвеєр сканування; збереження історії сканувань у базі даних SQLite та формування звітності у форматах HTML, JSON, CSV та TXT.
Результати: розроблено модульну архітектуру на основі патерну "Оркестратор" із п'ятьма етапами сканування; реалізовано збір субдоменів через subfinder, assetfinder та crt.sh; DNS-резолвінг із фільтрацією Cloudflare IP; аналіз веб-сервісів через httpx; сканування портів через nmap; пошук вразливостей через nuclei, sqlmap, searchsploit та nmap NSE; розроблено схему бази даних із сімома таблицями; реалізовано генерацію HTML-звіту з графіками та описом CVE; проведено чотири види тестування.
Висновки: програмний комплекс суттєво скорочує час тестування web-ресурсів порівняно з ручним використанням інструментів; технології Python, PyQt6 та SQLite забезпечують стабільну роботу; модульна архітектура дозволяє легко розширювати функціональність системи. ANNOTATION Executor: Uvaiev Bohdan Serhiyovych. Title of the Bachelor's Qualification Work: "Software Complex for Automated Vulnerability Testing of Web Resources". Specialty: 121 "Software Engineering". Institution: Cherkasy State Technological University (CSTU). City, year: Cherkasy, 2026. Main ideas: development of a software complex for automated vulnerability testing of web resources with a graphical user interface based on PyQt6; integration of information security tools into a unified scanning pipeline; storage of scanning history in a SQLite database and generation of reports in HTML, JSON, CSV and TXT formats. Results: a modular architecture based on the "Orchestrator" pattern with five scanning stages has been developed; subdomain enumeration via subfinder, assetfinder and crt.sh has been implemented; DNS resolution with Cloudflare IP filtering; web service analysis via httpx; port scanning via nmap; vulnerability detection via nuclei, sqlmap, searchsploit and nmap NSE; a database schema with seven tables has been designed; HTML report generation with vulnerability charts and CVE descriptions has been implemented; four types of testing have been conducted. Conclusions: the software complex significantly reduces web resource testing time compared to manual tool usage; Python, PyQt6 and SQLite ensure stable system operation; the modular architecture allows easy extension of system functionality. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9670 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Уваєв Богдан Сергійович.pdf Restricted Access | 4.84 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: «Програмний комплекс тестування web-ресурсів на вразливість»
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Уваєв. Б. С.
(прізвище та ініціали)
Керівник Немченко В. В.
(прізвище та ініціали)
Рецензент Огніченко І.А.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
____________________ С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Уваєв Богдан Сергійович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програмний комплекс тестування web-ресурсів на вразливість
Керівник проекту (роботи) Немченко Вадим Вячеславович к.т.н.
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 12 » березня 2026 року
№56/03-03
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи) технічна документація інструментів інформаційної безпеки; вимоги до
програмного забезпечення; стандарти розробки програмних комплексів; методології тестування на
вразливість; специфікації форматів звітності.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Вступ;Аналіз предметної області та існуючих рішень; Проектування програмного комплексу;
Розробка та тестування програмного комплексу; Висновки; Список використаних джерел; Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Додаток А – Документація Додаток Б – Специфікація програми Додаток В – Текст програми
Додаток Г – Презентаційний матеріал
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання грудня 2025 року
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційноїр
оботи
1 Постановка задачі 05.12.2025 виконано
2 Підготовка завдання 13.12.2025 виконано
3 Погодження завдання 16.12.2025 виконано
4 Затвердження завдання 19.02.2026 виконано
Основна стадія
1 Підбір матеріалів 27.02.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.02.2026 виконано
3 Розрахунок основних параметрів роботи 10.03.2026 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2026 виконано
5 Оформлення первісної редакції роботи 25.03.2026 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.04.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2026 виконано
кінцевій редакції
3 Попередній захист роботи 15.05.2026 виконано
4 Затвердження роботи 02.06.2026 виконано
5 Рецензування роботи 06.06.2026 виконано
6 Захист роботи 12.06.2026 виконано
Студент _____________________ Уваєв Б. С.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Немченко В. В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Виконавець: Уваєв Богдан Сергійович.
Назва кваліфікаційної бакалаврської роботи: "Програмний комплекс
автоматизованого тестування web-ресурсів на вразливість".
Спеціальність: 121 «Інженерія програмного забезпечення».
Установа: Черкаський державний технологічний університет (ЧДТУ).
Місто, рік: Черкаси, 2026 рік.
Основні ідеї: розробка програмного комплексу для автоматизованого
тестування web-ресурсів на вразливість із графічним інтерфейсом на базі PyQt6;
об'єднання інструментів інформаційної безпеки в єдиний конвеєр сканування;
збереження історії сканувань у базі даних SQLite та формування звітності у
форматах HTML, JSON, CSV та TXT.
Результати: розроблено модульну архітектуру на основі патерну
"Оркестратор" із п'ятьма етапами сканування; реалізовано збір субдоменів через
subfinder, assetfinder та crt.sh; DNS-резолвінг із фільтрацією Cloudflare IP; аналіз
веб-сервісів через httpx; сканування портів через nmap; пошук вразливостей через
nuclei, sqlmap, searchsploit та nmap NSE; розроблено схему бази даних із сімома
таблицями; реалізовано генерацію HTML-звіту з графіками та описом CVE;
проведено чотири види тестування.
Висновки: програмний комплекс суттєво скорочує час тестування web-
ресурсів порівняно з ручним використанням інструментів; технології Python,
PyQt6 та SQLite забезпечують стабільну роботу; модульна архітектура дозволяє
легко розширювати функціональність системи.
Ключові слова: тестування на вразливість, пентестинг, веб-безпека,
автоматизоване сканування, python, субдомени, CVE, звітність, інформаційна
безпека.
ANNOTATION
Executor: Uvaiev Bohdan Serhiyovych.
Title of the Bachelor's Qualification Work: "Software Complex for Automated
Vulnerability Testing of Web Resources".
Specialty: 121 "Software Engineering".
Institution: Cherkasy State Technological University (CSTU).
City, year: Cherkasy, 2026.
Main ideas: development of a software complex for automated vulnerability
testing of web resources with a graphical user interface based on PyQt6; integration of
information security tools into a unified scanning pipeline; storage of scanning history in
a SQLite database and generation of reports in HTML, JSON, CSV and TXT formats.
Results: a modular architecture based on the "Orchestrator" pattern with five
scanning stages has been developed; subdomain enumeration via subfinder, assetfinder
and crt.sh has been implemented; DNS resolution with Cloudflare IP filtering; web
service analysis via httpx; port scanning via nmap; vulnerability detection via nuclei,
sqlmap, searchsploit and nmap NSE; a database schema with seven tables has been
designed; HTML report generation with vulnerability charts and CVE descriptions has
been implemented; four types of testing have been conducted.
Conclusions: the software complex significantly reduces web resource testing time
compared to manual tool usage; Python, PyQt6 and SQLite ensure stable system
operation; the modular architecture allows easy extension of system functionality.
Keywords: vulnerability testing, penetration testing, web security, automated
scanning, python, subdomains, CVE, reporting, information security.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ........................................................................ 7
ВСТУП .......................................................................................................................... 9
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ ................................................................................................................... 13
1.1. Аналіз технічної інформації .......................................................................... 13
1.2. Актуальність задачі ........................................................................................ 14
1.3. Аналіз існуючих програмних засобів .......................................................... 15
1.4. Аналіз способів вирішення задачі ................................................................ 17
1.5. Постановка задачі ........................................................................................... 18
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ ................................................................. 20
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ .................................................................................................................... 21
2.1. Моделювання предметної області ................................................................ 21
2.1.1. Предметна область моделювання. Модель предметної області. Словник
предметної області ............................................................................................ 22
2.1.2. Елементи моделювання предметної області ........................................ 24
2.1.3. Робоча область моделювання ................................................................ 26
2.2. Формування та аналіз вимог ......................................................................... 26
ЧДТУ 262265.026 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Уваєв Б. С.
Перевір Немченко В. В. «Програмний комплекс Літ. Лист Листів
Н. Контр. Півень О. Б. тестування web- 4
ресурсів на ФІТІС, кафедра ПЗАС, ПЗ-
Затверд. Голуб С. В. вразливість» 2204
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги. ................................................................................................................ 27
2.2.2. Формування вимог за допомогою діаграми прецедентів .................... 29
2.3. Проектування логічної структури програмного комплексу ...................... 32
2.3.1. Діаграми класів ........................................................................................ 32
2.3.2 Діаграми пакетів ....................................................................................... 35
2.4. Архітектурне проектування .......................................................................... 37
2.4.1. Діаграма компонентів ............................................................................. 37
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ........................................................................................................ 40
2.5. Моделювання поведінки системи................................................................. 42
2.5.1. Діаграма діяльності ................................................................................. 42
2.5.2. Діаграма послідовності ........................................................................... 44
2.5.3. Діаграма комунікації ............................................................................... 48
2.5.4. Діаграма скінченного автомату ............................................................. 50
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ ................................................................... 57
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ58
3.1. Розробка програмного комплексу. ............................................................... 58
3.1.1. Обґрунтування вибору засобів реалізації. ............................................ 58
3.1.2. Опис структурної (функціональної) схеми .......................................... 60
3.1.3. Опис логічної схеми системи ................................................................. 64
3.1.4. Розробка бази даних ................................................................................ 68
3.1.5. Розробка інтерфейсу користувача ......................................................... 70
ЧДТУ 262265.026 ПЗ
Змн. Арк. № докум. Підпис Дата
3.1.6. Опис розробки програмних компонентів ............................................. 72
3.2. Тестування системи ....................................................................................... 75
3.2.1. Модульне тестування .............................................................................. 76
3.2.2. Інтеграційне тестування ......................................................................... 79
3.2.3. Системне тестування .............................................................................. 83
3.2.4. Приймальне тестування .......................................................................... 86
3.3. Приклади впровадженого програмного комплексу .................................... 89
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ ................................................................. 94
ВИСНОВКИ ............................................................................................................... 95
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 97
ДОДАТОК А ............................................................................................................ 101
ДОДАТОК Б ............................................................................................................ 103
ДОДАТОК В ............................................................................................................ 124
ДОДАТОК Г ............................................................................................................ 136
ЧДТУ 262265.026 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 262265.026 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
API (Application Programming Interface) – програмний інтерфейс застосунку,
набір правил та протоколів для взаємодії між програмними компонентами.
CVE (Common Vulnerabilities and Exposures) – загальний перелік відомих
вразливостей та загроз інформаційній безпеці.
CWE (Common Weakness Enumeration) – загальний перелік слабких місць
програмного забезпечення.
CSV (Comma-Separated Values) – формат зберігання табличних даних у
вигляді текстового файлу з роздільниками.
DNS (Domain Name System) – система доменних імен, що забезпечує
перетворення доменних імен на IP-адреси.
GUI (Graphical User Interface) – графічний інтерфейс користувача.
HTML (HyperText Markup Language) – мова розмітки гіпертексту для
створення веб-сторінок.
HTTP (HyperText Transfer Protocol) – протокол передачі гіпертексту для
обміну даними у веб.
HTTPS (HyperText Transfer Protocol Secure) – захищена версія протоколу
HTTP із шифруванням даних.
IP (Internet Protocol) – міжмережевий протокол, що забезпечує адресацію та
маршрутизацію пакетів у мережі.
JSON (JavaScript Object Notation) – текстовий формат обміну даними, що
базується на синтаксисі JavaScript.
NSE (Nmap Scripting Engine) – механізм скриптів інструменту Nmap для
розширеного аналізу мережевих сервісів.
OWASP (Open Web Application Security Project) – міжнародна некомерційна
організація, що займається підвищенням безпеки програмного забезпечення.
7
ЧДТУ 262265.026 ПЗ
OSINT (Open Source Intelligence) – збір та аналіз інформації з відкритих
джерел.
RAG – розвідка та збір інформації (Reconnaissance And Gathering).
SQL (Structured Query Language) – мова структурованих запитів для роботи
з реляційними базами даних.
SQLite – легка реляційна система управління базами даних, що зберігає дані
у єдиному файлі.
TCP (Transmission Control Protocol) – транспортний протокол передачі даних.
TXT – текстовий формат файлу без форматування.
UML (Unified Modeling Language) – уніфікована мова моделювання для
візуалізації та проектування програмних систем.
URL (Uniform Resource Locator) – уніфікований локатор ресурсів, адреса
ресурсу в мережі Інтернет.
WAF (Web Application Firewall) – міжмережевий екран для веб-застосунків.
Web – сукупність веб-ресурсів, технологій та сервісів, що функціонують у
мережі Інтернет.
XSS (Cross-Site Scripting) – міжсайтовий скриптинг, тип вразливості веб-
застосунків.
XML (eXtensible Markup Language) – розширювана мова розмітки для
зберігання та передачі даних.
БД – база даних.
ПЗ – програмне забезпечення.
СУБД – система управління базами даних.
8
ЧДТУ 262265.026 ПЗ
ВСТУП
Актуальність теми. Інженерія програмного забезпечення розглядає
забезпечення інформаційної безпеки веб-ресурсів як один із пріоритетних
напрямів розвитку сучасних інформаційних технологій. Веб-додатки широко
використовуються у різних сферах діяльності, включаючи електронну комерцію,
банківські системи, державні сервіси та корпоративні інформаційні системи. У
зв’язку з цим зростає кількість кіберзагроз, спрямованих на виявлення та
експлуатацію вразливостей веб-ресурсів.
Згідно з рекомендаціями OWASP [1], більшість атак на веб-додатки
пов’язані з типовими вразливостями, такими як SQL-ін’єкції, міжсайтовий
скриптинг (XSS), порушення автентифікації та витік конфіденційної інформації.
Для виявлення таких загроз застосовуються спеціалізовані інструменти, зокрема
Nmap, Dirsearch, ffuf та інші [9].
Однак з точки зору інженерії програмного забезпечення використання
окремих інструментів не забезпечує комплексного підходу до аналізу безпеки,
оскільки вони орієнтовані на виконання вузькоспеціалізованих задач і не
інтегровані в єдине програмне середовище. Це ускладнює проектування надійних
та масштабованих рішень для тестування безпеки, призводить до необхідності
ручної інтеграції результатів та значних витрат часу на розробку і налаштування.
На даний час не існує універсального та повністю автоматизованого
рішення, яке б забезпечувало інтеграцію різних етапів тестування веб-ресурсів у
єдину систему. Саме тому розробка програмного комплексу для автоматизованого
тестування веб-сайтів на вразливості є актуальною задачею.
Мета розробки. Метою даної кваліфікаційної роботи є розробка
програмного комплексу для автоматизованого тестування веб-ресурсів на
наявність вразливостей, який забезпечить інтеграцію різних інструментів аналізу,
обробку результатів та формування підсумкового звіту.
Завдання розробки. Для досягнення поставленої мети необхідно вирішити
наступні завдання:
– провести аналіз існуючих методів та засобів тестування веб-ресурсів;
9
ЧДТУ 262265.026 ПЗ
– дослідити сучасні підходи до автоматизації процесу тестування;
– розробити архітектуру програмного комплексу;
– реалізувати механізм послідовного запуску інструментів тестування
(pipeline);
– забезпечити передачу даних між етапами тестування;
– реалізувати систему збереження результатів із використанням бази даних
SQLite;
– розробити механізми парсингу та уніфікації результатів роботи
інструментів;
– створити інтерфейс для відображення процесу та результатів тестування;
– реалізувати генерацію підсумкового звіту у форматі PDF.
Об’єктом розробки є процеси автоматизованого тестування веб-ресурсів на
наявність вразливостей.
Предметом розробки є методи, алгоритми та програмні засоби інтеграції
інструментів тестування веб-ресурсів, а також обробка, збереження та
представлення результатів аналізу.
Методи проєктування та конструювання. Для досягнення поставленої
мети у роботі використано наступні методи та засоби:
− мова програмування Python [14] – для реалізації логіки програмного
комплексу, інтеграції зовнішніх інструментів та обробки результатів;
− база даних SQLite [16] – для централізованого збереження результатів
тестування;
− інтегроване середовище розробки Visual Studio Code – використовується
для написання, редагування та налагодження програмного коду;
− система контролю версій Git та платформа GitHub – застосовуються для
відстеження змін у коді та організації процесу розробки;
− використання зовнішніх інструментів, зокрема Nmap, Sublist3r, httpx,
WhatWeb, Dirsearch, ffuf;
− методи парсингу та обробки даних – для уніфікації результатів роботи
інструментів;
10
ЧДТУ 262265.026 ПЗ
− системний підхід – при проектуванні архітектури програмного
комплексу;
− моделювання – при побудові структури взаємодії компонентів системи;
− експеримент – при перевірці працездатності розробленого програмного
забезпечення;
− використання UML-діаграм (Unified Modeling Language) [21] –
застосовується для візуалізації структури та поведінки системи, що
розробляється.
Опис отриманих результатів. У ході виконання кваліфікаційної роботи
було розроблено програмний комплекс для тестування веб-ресурсів на
вразливості, який забезпечує автоматизований запуск інструментів аналізу
відповідно до заданого алгоритму.
Реалізовано механізм послідовного виконання етапів тестування, у межах
якого результати роботи кожного інструмента передаються до наступного через
базу даних. Забезпечено збереження результатів у структурованому вигляді, що
дозволяє виконувати їх подальший аналіз.
Розроблено модулі парсингу результатів роботи інструментів та їх
уніфікації. Реалізовано інтерфейс для відображення процесу тестування та
отриманих результатів.
Також реалізовано механізм формування підсумкового звіту у форматі PDF,
який містить інформацію про виявлені вразливості та оцінку рівня безпеки веб-
ресурсу.
Практичне значення отриманих результатів. Розроблений програмний
комплекс дозволяє автоматизувати процес тестування веб-ресурсів, що значно
зменшує витрати часу та підвищує ефективність аналізу.
Система може бути використана:
− спеціалістами з кібербезпеки для проведення первинного аналізу веб-
ресурсів;
− розробниками для перевірки власних веб-додатків;
− у навчальному процесі для демонстрації принципів тестування безпеки.
11
ЧДТУ 262265.026 ПЗ
Завдяки використанню централізованого зберігання даних та
автоматизованої генерації звітів, підвищується зручність роботи з результатами
тестування та їх подальшого використання.
Особистий внесок автора. Усі результати, представлені в даній
кваліфікаційній роботі, отримані автором самостійно. Автором проведено аналіз
існуючих методів та засобів тестування веб-ресурсів, розроблено архітектуру
програмного комплексу, реалізовано програмне забезпечення, виконано
тестування системи та проаналізовано отримані результати.
12
ЧДТУ 262265.026 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Аналіз технічної інформації
Інженерія програмного забезпечення визначає автоматизоване тестування
безпеки веб-ресурсів як один із важливих напрямків сучасної інформаційної
безпеки. Зі збільшенням кількості веб-додатків та складності їх архітектури
зростає потреба у швидкому виявленні потенційних вразливостей та аналізі
конфігурації систем. Сучасні веб-ресурси можуть включати велику кількість
компонентів: веб-сервери, API, бази даних, піддомени, балансувальники
навантаження, системи захисту та сторонні сервіси. Це значно ускладнює процес
аналізу безпеки.
Під час проведення тестування на проникнення (penetration testing) одним із
ключових етапів є розвідка цільової системи (reconnaissance). Основною метою
цього етапу є збір максимальної кількості інформації про цільовий ресурс.
Отримані дані надалі використовуються для аналізу потенційних точок атаки та
пошуку відомих вразливостей.
Для виконання завдань розвідки використовуються спеціалізовані
інструменти, кожен з яких вирішує окрему задачу:
– Subfinder, Amass, crtzh [5] – використовуються для пошуку субдоменів та
розширення області дослідження цільового ресурсу;
– HTTPX [8] – виконує перевірку активності веб-сервісів, аналізує HTTP-
відповіді, статус-коди та визначає доступність веб-ресурсів;
– Nmap [9] – призначений для сканування мережевих вузлів, визначення
відкритих портів та аналізу мережевих сервісів;
– Nuclei [10] – застосовується для автоматичного пошуку відомих
вразливостей за допомогою шаблонів;
– SQLMap [11] – використовується для виявлення SQL-ін'єкцій та
автоматизованого аналізу взаємодії з базами даних;
13
ЧДТУ 262265.026 ПЗ
– Searchsploit [12] – дозволяє знаходити публічні експлойти на основі
виявлених версій програмного забезпечення;
– Nmap NSE [9] – набір скриптів для розширеного аналізу сервісів та
виявлення вразливостей.
Незважаючи на високу ефективність окремих утиліт, більшість із них
функціонують як незалежні консольні інструменти та потребують ручного запуску
й обробки результатів. Під час виконання комплексного тестування спеціалісту
необхідно запускати велику кількість програм, передавати результати між ними та
виконувати додаткову обробку отриманих даних.
Крім того, результати роботи різних інструментів можуть повертатися у
різних форматах: JSON, XML, TXT або табличному вигляді. Це створює додаткові
труднощі при централізованому збереженні, аналізі та формуванні підсумкових
звітів.
Таким чином, аналіз технічної інформації показав, що сучасний процес
тестування безпеки веб-ресурсів базується на використанні великої кількості
спеціалізованих засобів. Їх інтеграція в єдину систему дозволяє спростити процес
аналізу, автоматизувати передачу даних між етапами сканування та підвищити
ефективність виконання задач тестування безпеки.
1.2. Актуальність задачі
Інженерія програмного забезпечення визначає розробку автоматизованих
засобів тестування безпеки як актуальну задачу, оскільки веб-додатки є основою
функціонування значної кількості інформаційних систем, корпоративних сервісів,
електронної комерції та онлайн-платформ. Разом із розвитком веб-технологій
зростає і кількість потенційних загроз інформаційній безпеці. Наявність відкритих
портів, некоректних налаштувань серверів, застарілих компонентів, помилок
конфігурації та програмних вразливостей може призводити до несанкціонованого
доступу, витоку інформації або компрометації інформаційних систем.
Для аналізу захищеності веб-ресурсів використовуються різні спеціалізовані
інструменти, зокрема засоби пошуку субдоменів, сканери мережевої
14
ЧДТУ 262265.026 ПЗ
інфраструктури, системи визначення технологічного стеку та інструменти
автоматизованого виявлення відомих вразливостей. Проте більшість таких засобів
функціонують як окремі програмні рішення та потребують ручного налаштування,
запуску і подальшої обробки отриманих результатів.
Під час проведення тестування безпеки спеціаліст змушений послідовно
використовувати декілька незалежних утиліт та передавати інформацію між
етапами аналізу вручну. Це збільшує час виконання перевірки, ускладнює процес
збору та систематизації результатів, а також підвищує ймовірність втрати важливої
інформації.
Додатковою проблемою є відсутність централізованого збереження
результатів, автоматичного формування звітності та механізмів взаємодії між
окремими інструментами в єдиному програмному середовищі. Через це виникає
необхідність створення програмного комплексу, який дозволить автоматизувати
процес збору інформації, виконання перевірок, аналізу результатів та формування
звітів.
Таким чином, розробка автоматизованої системи для проведення розвідки та
пошуку вразливостей веб-ресурсів є актуальною задачею, оскільки дозволяє
скоротити час виконання тестування, підвищити ефективність аналізу та
спростити роботу спеціалістів з інформаційної безпеки.
1.3. Аналіз існуючих програмних засобів
Для проведення тестування веб-ресурсів на наявність потенційних
вразливостей використовуються спеціалізовані програмні засоби, які дозволяють
виконувати окремі етапи аналізу цільової системи. Найчастіше процес тестування
складається з етапів збору інформації, пошуку субдоменів, визначення активних
сервісів, аналізу мережевої інфраструктури та перевірки наявності відомих
вразливостей.
Одним із найбільш поширених інструментів є Nmap, який використовується
для сканування мережі та виявлення відкритих портів, служб і версій сервісів.
Даний інструмент дозволяє отримувати інформацію про мережеву структуру
15
ЧДТУ 262265.026 ПЗ
цільової системи та підтримує використання спеціалізованих NSE-скриптів для
пошуку вразливостей. Перевагою Nmap є висока точність аналізу та широкий набір
функцій. Недоліком є складність налаштування та необхідність додаткового
аналізу результатів.
Для пошуку субдоменів часто використовуються інструменти Subfinder,
Amass та Findomain [5]. Їх основне призначення полягає у зборі інформації про
піддомени цільового ресурсу з використанням відкритих джерел інформації та
пошукових сервісів. Використання таких інструментів дозволяє розширити
область аналізу, проте результати можуть дублюватися або містити неактивні
записи.
Для перевірки активності веб-ресурсів використовується утиліта HTTPX [8].
Вона виконує HTTP-запити до знайдених адрес, визначає статус доступності, тип
веб-сервера, використовувані технології та інші параметри веб-ресурсу.
Інструмент значно спрощує процес фільтрації активних ресурсів, однак не виконує
повноцінного аналізу безпеки.
Для автоматизованого пошуку відомих вразливостей застосовується
Nuclei [10]. Його робота базується на використанні шаблонів, які дозволяють
знаходити відомі вразливості, помилки конфігурації та типові проблеми безпеки.
Перевагою інструмента є велика база шаблонів та висока швидкість роботи.
Водночас ефективність напряму залежить від актуальності шаблонів.
Також для пошуку SQL-ін'єкцій використовується SQLMap [11], який
автоматизує перевірку параметрів веб-додатка на наявність відповідних
вразливостей. Даний інструмент дозволяє виконувати поглиблений аналіз, але
потребує значного часу під час сканування великих систем.
Незважаючи на широкі функціональні можливості перелічених засобів,
більшість із них працюють як окремі незалежні утиліти. Це ускладнює організацію
єдиного процесу тестування, потребує ручної передачі даних між етапами аналізу
та не забезпечує централізованого зберігання результатів. Саме тому виникає
необхідність інтеграції декількох інструментів у єдиний програмний комплекс із
автоматизованим конвеєром обробки даних.
16
ЧДТУ 262265.026 ПЗ
1.4. Аналіз способів вирішення задачі
Існує декілька підходів до вирішення задачі автоматизації процесу
тестування веб-ресурсів на наявність потенційних вразливостей. Кожен із підходів
має власні особливості, переваги та обмеження залежно від способу організації
процесу збору та обробки інформації.
Першим способом є використання окремих спеціалізованих утиліт у
ручному режимі. У даному випадку спеціаліст самостійно запускає інструменти
для пошуку субдоменів, аналізу мережевої інфраструктури, сканування портів та
пошуку вразливостей, а також виконує подальшу обробку отриманих результатів.
Такий підхід дозволяє гнучко керувати процесом аналізу та налаштовувати
параметри кожного інструмента окремо. Проте використання великої кількості
програмних засобів значно ускладнює процес роботи та потребує додаткового часу
на обробку результатів.
Іншим способом є застосування готових комплексних платформ для
тестування безпеки, які поєднують декілька механізмів аналізу в єдиній системі.
Такі рішення дозволяють автоматизувати окремі етапи перевірки, централізовано
зберігати інформацію та генерувати звіти. Однак більшість подібних платформ
мають обмеження щодо функціональних можливостей, можуть вимагати платної
ліцензії або не забезпечувати достатньої гнучкості для інтеграції сторонніх
інструментів.
Ще одним підходом є створення власного програмного комплексу на основі
модульної архітектури. При такому підході окремі інструменти об'єднуються в
єдину систему, де результати роботи одного модуля автоматично передаються
наступному етапу обробки. Додатково забезпечується централізоване збереження
інформації, можливість повторного перегляду результатів та автоматичне
формування звітів.
Для реалізації такого підходу доцільним є використання архітектури типу
Pipeline [39], яка дозволяє організувати послідовний потік обробки даних між
модулями системи. Результати кожного етапу стають вхідними даними для
17
ЧДТУ 262265.026 ПЗ
наступного, що мінімізує ручне втручання користувача та забезпечує
автоматизацію процесу сканування.
Проведений аналіз показує, що найбільш ефективним способом вирішення
поставленої задачі є розробка власного програмного комплексу, який
поєднуватиме переваги спеціалізованих інструментів, забезпечуватиме
автоматизацію процесів аналізу та використовуватиме єдину систему керування
результатами сканування.
1.5. Постановка задачі
На основі проведеного аналізу існуючих програмних засобів та способів
вирішення задачі було встановлено, що процес тестування веб-ресурсів на
наявність вразливостей часто виконується із використанням великої кількості
окремих інструментів. Це призводить до ускладнення процесу роботи, збільшення
часу аналізу та необхідності ручної обробки результатів.
Основною задачею кваліфікаційної роботи є розробка програмного
комплексу для автоматизації процесу проведення розвідки та аналізу веб-ресурсів
з метою виявлення потенційних вразливостей. Система повинна забезпечувати
інтеграцію декількох спеціалізованих інструментів в єдине програмне середовище
та організовувати їхню взаємодію в автоматичному режимі.
Для досягнення поставленої мети необхідно вирішити такі задачі:
– провести аналіз існуючих методів та засобів тестування безпеки веб-
ресурсів;
– дослідити сучасні інструменти для пошуку субдоменів, сканування
мережевої інфраструктури та аналізу вразливостей;
– виконати моделювання предметної області та сформувати вимоги до
програмного забезпечення;
– розробити архітектуру програмного комплексу з використанням
модульного підходу;
– реалізувати механізм автоматизованої взаємодії між модулями системи
на основі конвеєрної обробки даних;
18
ЧДТУ 262265.026 ПЗ
– реалізувати графічний інтерфейс користувача для керування процесом
сканування;
– забезпечити збереження результатів у базі даних та можливість
перегляду історії сканувань;
– реалізувати механізм формування звітів у різних форматах експорту;
– провести тестування розробленого програмного забезпечення та оцінити
ефективність його роботи.
У результаті виконання поставлених задач планується отримати програмний
комплекс, який дозволить автоматизувати процес тестування веб-ресурсів,
скоротити час проведення аналізу та підвищити зручність роботи користувача.
19
ЧДТУ 262265.026 ПЗ
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ
У розділі проведено аналіз існуючих методів та засобів тестування web-
ресурсів на вразливість, досліджено сучасні інструменти інформаційної безпеки та
обґрунтовано необхідність розробки власного програмного комплексу.
Аналіз технічної інформації показав, що процес тестування безпеки web-
ресурсів базується на використанні великої кількості спеціалізованих утиліт,
кожна з яких вирішує окрему задачу: subfinder, assetfinder та crt.sh – для збору
субдоменів, httpx – для аналізу веб-сервісів, nmap – для сканування портів, nuclei,
sqlmap та searchsploit – для виявлення вразливостей. Незважаючи на високу
ефективність окремих інструментів, більшість із них функціонують як незалежні
консольні утиліти та потребують ручного запуску й обробки результатів.
Аналіз існуючих програмних засобів виявив, що відсутність
централізованого збереження результатів, необхідність ручної передачі даних між
етапами аналізу та різноформатність вихідних даних суттєво ускладнюють процес
комплексного тестування та збільшують час його виконання.
Аналіз способів вирішення задачі показав, що найбільш ефективним
підходом є розробка власного програмного комплексу на основі модульної
архітектури типу Pipeline, який забезпечить автоматизовану взаємодію між
інструментами, централізоване збереження результатів та автоматичне
формування звітності.
На основі проведеного аналізу сформульовано постановку задачі та
визначено перелік завдань, які необхідно вирішити в рамках кваліфікаційної
роботи: розробити архітектуру програмного комплексу, реалізувати конвеєрний
механізм обробки даних, графічний інтерфейс користувача, систему збереження
результатів у базі даних та модуль формування звітів у різних форматах експорту.
20
ЧДТУ 262265.026 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
2.1. Моделювання предметної області
Предметною областю розроблюваної системи є автоматизоване тестування
веб-ресурсів на наявність вразливостей та збір інформації про цільові веб-системи.
Процес аналізу безпеки веб-ресурсів включає виявлення субдоменів, визначення
мережевої інфраструктури, аналіз доступних сервісів, ідентифікацію
використовуваних технологій та пошук потенційних вразливостей.
У традиційному підході для виконання повноцінного тестування
використовуються різні спеціалізовані інструменти, кожен з яких виконує окрему
задачу. Це зумовлює необхідність ручної передачі результатів між етапами
сканування, повторного запуску утиліт та обробки результатів у різних форматах.
Для усунення зазначених недоліків у межах кваліфікаційної роботи
пропонується програмний комплекс, що реалізує централізований підхід до
автоматизації процесу тестування. Система виконує роль єдиного середовища
керування інструментами сканування та забезпечує автоматизовану передачу
даних між модулями.
До основних об'єктів предметної області належать:
– ціль тестування (домен або веб-ресурс);
– сесія сканування;
– субдомени;
– IP-адреси;
– мережеві порти;
– використовувані технології;
– вразливості;
– звіти тестування.
Під час роботи системи користувач задає домен, після чого програмний
комплекс виконує послідовне проходження етапів конвеєра сканування.
21
ЧДТУ 262265.026 ПЗ
Результати кожного етапу зберігаються у базі даних та використовуються
наступними компонентами системи.
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання. Предметною областю розроблюваного
програмного комплексу є автоматизоване тестування веб-ресурсів на наявність
потенційних вразливостей. Вона охоплює процеси збору інформації про цільовий
ресурс, аналізу мережевої інфраструктури, виявлення активних сервісів,
сканування відкритих портів та пошуку можливих загроз інформаційній безпеці.
Особливістю предметної області є послідовна обробка та передача даних між
етапами аналізу для отримання комплексних результатів тестування.
Модель предметної області. Модель предметної області представляє
структуру програмного комплексу автоматизованого тестування web-ресурсів.
Центральним елементом системи є графічний інтерфейс користувача (GUI), через
який користувач взаємодіє з програмою, задає ціль сканування та переглядає
результати аналізу.
Після запуску процесу тестування керування передається менеджеру задач
(Task Manager), який виконує роль центрального координатора системи. Даний
компонент відповідає за створення сесії сканування та послідовний запуск модулів
аналізу.
Першим етапом роботи системи є модуль збору субдоменів (Subdomain
Enumeration Module), який виконує пошук доступних піддоменів цільового веб-
ресурсу. Отримані результати передаються модулю DNS-резолвінгу (DNS
Resolver), що визначає активні вузли та отримує їх IP-адреси.
Далі модуль веб-аналізу (HTTPX Module) виконує перевірку доступності
веб-сервісів, отримує HTTP-відповіді та визначає технології, що
використовуються цільовим ресурсом. Після цього модуль сканування портів
(Nmap Module) здійснює аналіз відкритих мережевих портів і визначає доступні
служби.
22
ЧДТУ 262265.026 ПЗ
Завершальним етапом аналізу є модуль пошуку вразливостей (Vulnerability
Scanner Module), який використовує результати попередніх етапів для виявлення
потенційних загроз безпеці. Усі отримані дані зберігаються у базі даних, що
забезпечує централізоване накопичення та повторне використання результатів.
На основі накопиченої інформації модуль формування звітів (Export Module)
створює підсумкові звіти у різних форматах, що дозволяє користувачеві
виконувати подальший аналіз результатів тестування.
Таким чином, модель предметної області визначає основні структурні
елементи системи та взаємозв’язки між ними, що в подальшому використовуються
під час побудови UML-діаграм та проєктування архітектури програмного
комплексу.
Словник предметної області. Сформуємо словник предметної області
(табл. 2.1) та визначимо основні доменні об’єкти, що будуть використані під час
побудови моделі предметної області програмного комплексу тестування web-
ресурсів на вразливість.
Таблиця 2.1
Словник предметної області
№ Назва (укр.) Назва (англ.) Опис
1 Графічний Graphical User Інтерфейс взаємодії користувача з
інтерфейс Interface (GUI) програмним комплексом
2 Менеджер задач Task Manager Компонент, що керує запуском та
координацією модулів системи
3 Сесія сканування Scan Session Окремий процес запуску
тестування із збереженням
результатів
4 Модуль збору Subdomain Компонент пошуку субдоменів
субдоменів Enumeration Module цільового ресурсу
23
ЧДТУ 262265.026 ПЗ
Продовження таблиці 2.1
5 DNS-резолвер DNS Resolver Модуль перевірки активності
субдоменів та визначення IP-
адрес
6 Модуль веб-аналізу HTTPX Module Компонент визначення
доступності веб-сервісів та
технологій
7 Модуль сканування Nmap Module Компонент аналізу відкритих
портів портів і служб
8 Модуль пошуку Vulnerability Компонент виявлення
вразливостей Scanner Module потенційних вразливостей
9 База даних Database Система збереження результатів
тестування
10 Модуль Export Module Компонент створення
формування звітів підсумкових звітів
2.1.2. Елементи моделювання предметної області
Одним із етапів моделювання предметної області є визначення графічних
елементів та позначень, що будуть використовуватись при побудові UML-діаграм
програмного комплексу тестування web-ресурсів на вразливість. Використання
уніфікованої мови моделювання UML дозволяє формалізувати структуру
програмної системи, описати взаємодію компонентів та представити логіку роботи
програмного забезпечення у графічному вигляді.
Для моделювання архітектури та поведінки програмного комплексу
планується використання елементів, наведених у таблиці 2.2.
Таблиця містить графічні символи та їх назви відповідно до стандарту UML
2.0, які застосовуються для побудови структурних та поведінкових діаграм
програмного комплексу, зокрема діаграм варіантів використання, класів,
компонентів, розгортання та діаграм поведінки системи.
24
ЧДТУ 262265.026 ПЗ
Таблиця 2.2
Графічні символи UML діаграм, що плануються до використання
Графічний символ Назва елемента
Дійова особа (Actor)
Варіант використання (Use Case)
Коментар (Note)
Клас (Class)
Пакет (Package)
Об’єкт (Object)
Компонент (Component)
Потік виконання (Thread)
База даних (Database)
Вузол розгортання (Node)
Наступним етапом є визначення єднальних елементів UML, що
використовуватимуться для побудови зв’язків між компонентами системи
(табл. 2.3).
25
ЧДТУ 262265.026 ПЗ
Таблиця 2.3
Єднальні елементи UML, що плануються до використання
Графічний символ Назва елемента
Односпрямована асоціація (Unidirectional Association)
Асоціація (Association)
Агрегація (Aggregation)
Композиція (Composition)
Наслідування (Inheritance)
Залежність (Dependency)
Пряме повідомлення (Message)
Зворотне повідомлення (Return Message)
2.1.3. Робоча область моделювання
В якості робочої області моделювання розглянемо програмний комплекс
тестування web-ресурсів на вразливість. Користувач через графічний інтерфейс
вводить адресу цільового веб-ресурсу та запускає процес сканування. Після цього
система створює нову сесію аналізу та послідовно виконує етапи збору інформації:
пошук субдоменів, DNS-резолвінг, визначення доступних веб-сервісів, сканування
відкритих портів та пошук потенційних вразливостей.
У процесі роботи результати кожного етапу обробляються та зберігаються у
базі даних SQLite для подальшого використання. Користувач має можливість
спостерігати за ходом виконання сканування через вкладку логів, переглядати
результати аналізу та після завершення роботи формувати підсумковий звіт з
оцінкою безпеки веб-ресурсу.
2.2. Формування та аналіз вимог
Формування вимог є одним із ключових етапів проектування програмного
забезпечення, оскільки саме на цьому етапі визначаються основні можливості
26
ЧДТУ 262265.026 ПЗ
системи, особливості її функціонування та критерії якості. Аналіз вимог дозволяє
сформувати цілісне бачення майбутнього програмного комплексу, визначити
функціональні можливості системи та встановити обмеження щодо її реалізації.
Для розроблюваного програмного комплексу тестування web-ресурсів на
вразливість процес формування вимог здійснюється з урахуванням специфіки
автоматизації процесів аналізу інформаційної безпеки, особливостей роботи із
зовнішніми утилітами та необхідності обробки великої кількості результатів
сканування.
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги.
Формування вимог до програмного забезпечення
Процес формування вимог до програмного забезпечення передбачає
визначення характеристик майбутньої системи та опис її поведінки під час
взаємодії з користувачем. Вимоги визначають функціональність програмного
забезпечення, особливості роботи окремих компонентів та критерії ефективності
системи.
Для розроблюваного програмного комплексу основною задачею є
автоматизація процесу тестування web-ресурсів шляхом інтеграції декількох
інструментів інформаційної безпеки в єдину систему. Програмне забезпечення
повинно забезпечувати зручний механізм запуску сканування, виконання аналізу
та централізоване збереження отриманих результатів.
Первинні і детальні вимоги
Для початку сформуємо первинні вимоги, оскільки це дозволить більш
детально описати функціональні можливості системи.
Розроблюваний програмний комплекс призначений для автоматизованого
тестування web-ресурсів на наявність потенційних вразливостей. Після запуску
програми користувач повинен мати можливість ввести адресу цільового ресурсу
та розпочати процес сканування. Система повинна автоматично запускати
27
ЧДТУ 262265.026 ПЗ
необхідні модулі аналізу, обробляти результати роботи зовнішніх інструментів та
відображати інформацію у графічному інтерфейсі.
До детальних вимог належать:
– створення нової сесії сканування після запуску аналізу;
– автоматичний запуск модулів відповідно до визначеного конвеєра
обробки даних;
– відображення журналу роботи системи у режимі реального часу;
– збереження результатів сканування до бази даних SQLite;
– перегляд результатів у вигляді окремих вкладок;
– підтримка історії попередніх сесій;
– формування та експорт підсумкових звітів.
Вимоги замовника і розробника. Вимоги замовника передбачають
створення програмного комплексу, що дозволить автоматизувати процес
тестування web-ресурсів без необхідності ручного використання великої кількості
окремих інструментів. Система повинна забезпечувати зручний інтерфейс,
централізоване збереження результатів та автоматичне формування звітів.
Вимоги розробника є більш деталізованими. Користувач повинен мати
можливість ввести адресу ресурсу та запустити процес сканування через
графічний інтерфейс. Під час роботи система повинна відображати статус
виконання задач, інформаційні повідомлення та результати роботи модулів.
Функціональні та нефункціональні вимоги. До функціональних вимог
системи належать:
– введення користувачем адреси цільового web-ресурсу;
– запуск автоматизованого процесу сканування;
– пошук субдоменів;
– DNS-резолвінг та отримання IP-адрес;
– аналіз веб-сервісів та визначення технологій;
– сканування портів;
– пошук потенційних вразливостей;
– збереження результатів до бази даних;
28
ЧДТУ 262265.026 ПЗ
– перегляд історії сканувань;
– експорт результатів у файл.
До нефункціональних вимог належать:
– підтримка багатопотокового режиму роботи;
– відсутність блокування графічного інтерфейсу під час виконання
сканування;
– забезпечення модульної архітектури системи;
– підтримка роботи у середовищах Windows та Linux;
– можливість масштабування системи шляхом додавання нових модулів;
– забезпечення швидкого доступу до результатів сканування та історії
сесій.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Одним із підходів до формування діаграм прецедентів є декомпозиція
системи за функціональним призначенням. Для розроблюваного програмного
комплексу тестування web-ресурсів функціональність системи було розділено на
декілька взаємопов’язаних процесів: запуск сканування, виконання аналізу та
формування звітності.
Для проектування діаграм прецедентів використано програмний комплекс
Rational Rose [22], який дозволяє створювати UML-діаграми [21, 22], групувати
елементи за допомогою пакетів та використовувати їх у подальшому проектуванні
програмної системи.
Першим етапом сформуємо діаграму прецедентів запуску процесу
сканування, що наведена на рисунку 2.1.
Користувач (User) взаємодіє з такими сценаріями використання:
– запуск програми (Open Application), який ініціює роботу системи;
– введення адреси цільового web-ресурсу (Enter Target);
– запуск процесу сканування (Start Scan);
– перегляд журналу виконання (View Logs);
– зупинка процесу сканування (Stop Scan).
29
ЧДТУ 262265.026 ПЗ
Рисунок 2.1 – Діаграма прецедентів запуску сканування
Менеджер задач (Task Manager) бере участь у:
– створенні сесії сканування (Create Scan Session);
– запуску модулів аналізу (Run Modules);
– координації передачі даних між компонентами системи.
Наступним кроком сформуємо діаграму прецедентів процесу аналізу web-
ресурсу (рис. 2.2) та наведемо опис взаємодії її елементів.
Рисунок 2.2 – Діаграма прецедентів аналізу web-ресурсу
30
ЧДТУ 262265.026 ПЗ
Модулі аналізу (Scanning Modules) виконують:
– пошук субдоменів (Subdomain Enumeration);
– DNS-резолвінг (DNS Resolving);
– аналіз веб-сервісів (Web Analysis);
– сканування портів (Port Scanning);
– пошук вразливостей (Vulnerability Scanning).
База даних (Database) взаємодіє з процесами:
– збереження результатів (Save Results);
– отримання інформації про попередні сесії (Load Scan History).
Наступним етапом сформуємо діаграму прецедентів формування результатів
та звітності (рис. 2.3).
Користувач взаємодіє з такими функціями:
– перегляд результатів аналізу (View Results);
– перегляд історії сканувань (View History);
– формування звіту (Generate Report);
– експорт результатів (Export Results).
Рисунок 2.3 – Діаграма прецедентів формування результатів
Модуль експорту (Export Module) бере участь у:
– створенні HTML-звіту;
– формуванні JSON, CSV та TXT файлів;
– створенні підсумкової оцінки безпеки web-ресурсу.
31
ЧДТУ 262265.026 ПЗ
Зауважимо, що для логічного розділення функціональності системи
використано пакети (Packages). Це дозволяє повторно використовувати окремі
елементи діаграм, спрощує структуру проекту та підвищує зручність моделювання
складних програмних систем.
У процесі побудови діаграм прецедентів було визначено основні сценарії
взаємодії користувача із системою, що дозволить спростити подальше
проектування, тестування та реалізацію програмного комплексу.
2.3. Проектування логічної структури програмного комплексу
2.3.1. Діаграми класів
Наступним кроком спроектуємо та опишемо діаграму класів, що дозволить
спростити процес реалізації програмного забезпечення та визначити взаємозв’язки
між основними компонентами системи. Діаграма класів [22] дозволяє відобразити
логічну структуру програмного комплексу, його компоненти, атрибути та
взаємодію між окремими класами. Сформуємо діаграму класів без атрибутив, що
наведена на рисунку 2.4, та розглянемо її основні елементи.
Рисунок 2.4 - Діаграма класів без атрибутів
32
ЧДТУ 262265.026 ПЗ
Основні компоненти діаграми класів:
– MainWindow – реалізує графічний інтерфейс користувача та забезпечує
взаємодію між користувачем і програмним комплексом;
– ScanThread – виконує процес сканування в окремому потоці для
уникнення блокування графічного інтерфейсу;
– TaskManager – центральний компонент системи, який відповідає за
координацію роботи модулів та керування процесом сканування;
– BaseModule – базовий клас, що визначає загальну структуру та методи
роботи модулів;
– SubdomainEnumerationModule – виконує пошук субдоменів;
– DNSResolverModule – здійснює DNS-резолвінг та визначає IP-адреси
активних вузлів;
– HTTPXModule – аналізує веб-сервіси та визначає використовувані
технології;
– NmapModule – виконує сканування відкритих портів та служб;
– VulnerabilityScannerModule – відповідає за пошук потенційних
вразливостей;
– Database – забезпечує роботу з базою даних SQLite та збереження
результатів;
– ExportModule – формує звіти у форматах HTML, JSON, CSV та TXT.
Зв’язки між класами та основні дії:
– MainWindow взаємодіє із ScanThread для запуску процесу сканування;
– ScanThread створює екземпляр TaskManager та запускає його виконання;
– TaskManager послідовно викликає модулі аналізу;
– усі модулі успадковуються від класу BaseModule;
– результати роботи модулів передаються до Database для збереження;
– ExportModule отримує інформацію з бази даних та формує звіти;
– MainWindow отримує результати через механізм сигналів та оновлює
інтерфейс користувача.
33
ЧДТУ 262265.026 ПЗ
Рисунок 2.5 – Діаграма класів
34
ЧДТУ 262265.026 ПЗ
Приклади використання:
– користувач вводить адресу web-ресурсу через MainWindow;
– ScanThread запускає процес аналізу в окремому потоці;
– TaskManager створює нову сесію сканування;
– модулі послідовно виконують пошук субдоменів, аналіз сервісів та
перевірку вразливостей;
– результати зберігаються до бази даних;
– ExportModule формує підсумковий звіт на основі результатів сканування.
Слід зазначити, що використання діаграми класів дозволяє чітко
представити структуру системи та взаємозв’язки між її компонентами. Це значно
спрощує процес розробки, подальшого тестування та підтримки програмного
забезпечення. При цьому структура класів може змінюватися під час реалізації
системи, проте попереднє проектування дозволяє зменшити кількість
архітектурних змін на наступних етапах розробки.
2.3.2 Діаграми пакетів
Наступним кроком представимо діаграму пакетів, що наведена на
рисунку 2.6.
Рисунок 2.6 – Діаграма пакетів
35
ЧДТУ 262265.026 ПЗ
Діаграма включає декілька основних пакетів, які з’єднані спрямованими
асоціаціями, що відображають взаємозв’язки між окремими компонентами
системи:
– GUI, пакет, що містить компоненти графічного інтерфейсу користувача
та забезпечує взаємодію користувача із програмним комплексом. Даний
пакет містить головне вікно програми, вкладки результатів, систему
логування та елементи керування;
– Core, пакет, що містить основну логіку роботи системи. До нього входять
менеджер задач (TaskManager), механізми керування потоками
виконання та модулі координації роботи компонентів;
– Modules, пакет, який містить модулі аналізу та тестування web-ресурсів.
До його складу входять модулі пошуку субдоменів, DNS-резолвінгу,
аналізу веб-сервісів, сканування портів та пошуку вразливостей;
– Database, пакет, що відповідає за взаємодію із базою даних SQLite та
збереження результатів сканування;
– Utils, пакет допоміжних компонентів, який містить модулі експорту
результатів, обробки даних та службові функції.
Пакет GUI взаємодіє із пакетом Core, передаючи дані користувача та
отримуючи результати виконання задач. Пакет Core взаємодіє з Modules,
запускаючи окремі модулі аналізу та координуючи їх роботу. Після завершення
виконання результати передаються до пакету Database для збереження та
подальшого використання.
Пакет Utils використовує результати з бази даних та забезпечує формування
звітів і експорт інформації у необхідні формати.
Використання діаграми пакетів дозволяє представити модульну структуру
програмного комплексу, визначити взаємозалежності між його складовими та
спростити подальший процес реалізації й підтримки системи.
Таким чином, діаграма пакетів відображає модульну структуру програмного
комплексу та визначає межі відповідальності кожного пакету, що спрощує
подальший розвиток системи.
36
ЧДТУ 262265.026 ПЗ
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів
Одним із важливих етапів проектування програмного забезпечення є
формування діаграми компонентів. Вона дозволяє представити основні складові
системи, їх взаємодію та залежності між ними. Сформуємо діаграму компонентів
програмного комплексу тестування web-ресурсів на вразливість (рис. 2.7) та
наведемо її опис.
Рисунок 2.7 – Діаграма компонентів
37
ЧДТУ 262265.026 ПЗ
Основні елементи діаграми компонентів:
– компонент: User Interface (Користувацький інтерфейс);
− файл: main_window.py;
− вивід: взаємодія з користувачем, відображення логів та результатів;
− опис: забезпечує введення цільового домену, запуск процесу
сканування, перегляд отриманих результатів та експорт звітів.
– компонент: ScanThread (Потік сканування);
− файл: scan_thread.py;
− вивід: сигнали стану виконання процесів;
− опис: відповідає за запуск процесу сканування в окремому потоці для
уникнення блокування графічного інтерфейсу.
– компонент: TaskManager (Менеджер задач);
− файл: task_manager.py;
− вивід: структуровані результати сканування;
− опис: координує роботу всіх модулів системи, забезпечує
послідовний запуск етапів сканування та передачу результатів між
компонентами.
– компонент: Database (База даних);
− файл: database.py;
− вивід: записи SQLite;
− опис: забезпечує збереження результатів сканування, історії сесій та
інформації про знайдені вразливості.
– компонент: SubdomainEnumerationModule (Модуль пошуку субдоменів);
− вивід: список знайдених субдоменів;
− опис: використовує зовнішні інструменти для пошуку піддоменів
цільового ресурсу.
– компонент: DNSResolverModule (DNS-модуль);
− вивід: IP-адреси активних вузлів;
− опис: здійснює перевірку знайдених субдоменів та визначає їх IP-
38
ЧДТУ 262265.026 ПЗ
адреси.
– компонент: HTTPXModule (Модуль веб-аналізу);
− вивід: інформація про веб-сервери та технології;
− опис: визначає активні HTTP/HTTPS-сервіси та аналізує
використовувані технології.
– компонент: NmapModule (Модуль сканування портів);
− вивід: список відкритих портів та сервісів;
− опис: виконує сканування мережевих служб та визначення версій
сервісів.
– компонент: VulnerabilityScannerModule (Модуль пошуку вразливостей);
− вивід: перелік знайдених вразливостей;
− опис: використовує інструменти Nuclei, SQLMap, Searchsploit та NSE-
скрипти для виявлення відомих загроз.
– компонент: ExportModule (Модуль експорту);
− файл: export.py;
− вивід: HTML, JSON, CSV та TXT-звіти;
− опис: відповідає за формування звітів та генерацію підсумкового
документа.
Залежності та зв’язки між компонентами:
– User Interface взаємодіє із ScanThread для запуску сканування;
– ScanThread створює та запускає TaskManager;
– TaskManager виконує послідовний запуск модулів сканування;
– модулі аналізу передають результати один одному відповідно до етапів
Pipeline;
– отримані результати зберігаються у Database;
– ExportModule отримує інформацію з бази даних для формування звітів;
– User Interface отримує результати через сигнали та відображає їх
користувачу.
Використання діаграми компонентів дозволяє відобразити структуру
програмного комплексу та визначити взаємозв’язки між окремими складовими
39
ЧДТУ 262265.026 ПЗ
системи. Такий підхід спрощує реалізацію програмного забезпечення, покращує
його модульність та дозволяє надалі розширювати функціональність шляхом
додавання нових компонентів без зміни загальної архітектури системи.
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Одним із важливих етапів проектування програмного забезпечення є
визначення схеми розгортання системи на апаратних засобах. Діаграма
розгортання [22] дозволяє відобразити фізичне розташування компонентів
системи та взаємодію між ними. Сформуємо діаграму розгортання програмного
комплексу тестування web-ресурсів на вразливість (рисунок 2.8) та опишемо
основні компоненти.
Рисунок 2.8 – Діаграма розгортання
Основні елементи діаграми:
40
ЧДТУ 262265.026 ПЗ
– користувацький комп’ютер (Client Workstation) – персональний
комп’ютер користувача, на якому запускається програмний комплекс;
– Python Application – програмний комплекс, розроблений мовою Python із
використанням фреймворку PyQt6. Даний компонент містить графічний
інтерфейс користувача, логіку керування процесами та модулі взаємодії
із зовнішніми інструментами;
– SQLite Database – локальна база даних, яка використовується для
зберігання інформації про результати сканування, історію сесій, знайдені
субдомени, відкриті порти та вразливості;
– External Security Tools – зовнішні інструменти аналізу безпеки,
інтегровані у систему: Nmap, Subfinder, HTTPX, Nuclei, SQLMap,
Searchsploit та інші;
– Target Web Resource – цільовий web-ресурс, який аналізується системою;
– Generated Reports – модуль генерації звітів, який формує результати
сканування у форматах HTML, CSV, JSON та TXT.
Опис з’єднань:
– користувач взаємодіє з компонентом Python Application через графічний
інтерфейс;
– Python Application надсилає команди зовнішнім утилітам через механізм
запуску підпроцесів;
– зовнішні інструменти виконують аналіз та взаємодіють із цільовим web-
ресурсом;
– результати роботи інструментів повертаються до Python Application;
– програмний комплекс зберігає отримані дані у SQLite Database;
– модуль генерації звітів отримує результати із бази даних та створює
підсумкові документи.
Слід зауважити, що запропонована схема розгортання дозволяє реалізувати
програмний комплекс без використання окремого сервера чи хмарної
інфраструктури. Усі основні компоненти можуть працювати локально на
комп’ютері користувача, що спрощує процес розгортання, знижує вимоги до
41
ЧДТУ 262265.026 ПЗ
інфраструктури та забезпечує зручність використання системи.
2.5. Моделювання поведінки системи
2.5.1. Діаграма діяльності
Наступним етапом процесу проектування є формування діаграми діяльності.
Вона дозволяє відобразити послідовність дій системи, основні переходи між
станами та взаємодію користувача із програмним комплексом. Сформуємо
діаграму діяльності (рисунок 2.9) та наведемо її опис.
Рисунок 2.9 – Діаграма діяльності
42
ЧДТУ 262265.026 ПЗ
Опис елементів діаграми діяльності:
– відображення головного вікна (Display Main Window) – початковий стан
системи після запуску програмного комплексу. Користувачу
відображається графічний інтерфейс із можливістю введення цільового
домену;
– введення домену (Enter Target Domain) – користувач вводить адресу веб-
ресурсу для подальшого аналізу;
– запуск сканування (Start Scan) – користувач натискає кнопку початку
аналізу;
– створення сесії сканування (Create Scan Session) – система створює нову
сесію у базі даних для подальшого збереження результатів;
– рішення (Decision) – система перевіряє коректність введених даних.
При варіанті «ТАК»:
– пошук субдоменів (Subdomain Enumeration) – виконується пошук
піддоменів із використанням інтегрованих утиліт;
– DNS-резолвінг (DNS Resolution) – здійснюється перевірка знайдених
доменів та визначення IP-адрес;
– аналіз веб-сервісів (Web Service Analysis) – визначаються активні веб-
сервери та використовувані технології;
– сканування портів (Port Scanning) – виконується аналіз відкритих
мережевих портів;
– аналіз вразливостей (Vulnerability Scanning) – запускаються інструменти
пошуку потенційних загроз;
– злиття (Join) – система об’єднує результати виконаних модулів та готує
їх до збереження;
– збереження результатів (Save Results) – отримані дані записуються до
бази даних SQLite;
– відображення результатів (Display Results) – результати відображаються
у відповідних вкладках графічного інтерфейсу;
– генерація звіту (Generate Report) – формується підсумковий звіт
43
ЧДТУ 262265.026 ПЗ
у форматі HTML.
При варіанті «НІ»:
– відображення повідомлення про помилку (Display Error Message) –
система інформує користувача про неправильний формат введених
даних;
– завершення операції (Terminate Process) – процес сканування не
запускається.
Використання діаграми діяльності дозволяє наочно представити логіку
роботи програмного комплексу та послідовність виконання його функцій.
Діаграма також дозволяє виявити взаємозв’язки між окремими етапами аналізу,
визначити точки переходу між станами та спростити подальший процес реалізації
й тестування системи.
2.5.2. Діаграма послідовності
Наступним кроком спроектуємо та опишемо діаграму послідовності
(рис. 2.10), що відображає взаємодію між компонентами системи під час запуску
процесу сканування.
Послідовність взаємодії:
– користувач вводить адресу цільового ресурсу та надсилає повідомлення
(startScan) до головного вікна;
– головне вікно створює екземпляр потоку сканування та надсилає йому
повідомлення (run);
– потік сканування ініціалізує менеджер задач та передає йому
повідомлення (execute);
– менеджер задач надсилає повідомлення (createSession) до бази даних для
створення нового запису сесії;
– менеджер задач послідовно запускає модулі аналізу, надсилаючи
кожному повідомлення (run): SubdomainEnumerationModule,
DNSResolverModule, HTTPXModule, NmapModule,
VulnerabilityScannerModule;
44
ЧДТУ 262265.026 ПЗ
Рисунок 2.10 – Діаграма послідовності процесу сканування
45
ЧДТУ 262265.026 ПЗ
– кожен модуль після завершення роботи повертає структуровані
результати (results) до менеджера задач;
– менеджер задач надсилає повідомлення (saveResults) до бази даних для
збереження отриманих даних;
– потік сканування через механізм сигналів (pyqtSignal) надсилає
повідомлення (updateUI) до головного вікна;
– головне вікно оновлює вкладки результатів та відображає фінальний стан
сканування користувачу.
Опис об'єктів:
– користувач (User) – актор, який взаємодіє з програмним комплексом
через графічний інтерфейс;
– головне вікно (MainWindow) – компонент графічного інтерфейсу, що
забезпечує введення даних користувачем та відображення результатів;
– потік сканування (ScanThread) – компонент, що відповідає за запуск
процесу аналізу в окремому потоці виконання;
– менеджер задач (TaskManager) – центральний координатор системи, який
керує послідовним запуском модулів сканування;
– база даних (Database) – компонент збереження результатів сканування та
управління сесіями.
Наступним кроком спроектуємо та опишемо діаграму послідовності
формування та експорту звіту (рис. 2.11).
Опис об'єктів:
– користувач (User) – актор, що ініціює процес експорту результатів;
– головне вікно (MainWindow) – компонент інтерфейсу, що обробляє запит
на формування звіту;
– модуль експорту (ExportModule) – компонент, відповідальний за
отримання результатів із бази даних та генерацію звітів;
– база даних (Database) – джерело даних для формування звіту.
Послідовність взаємодії:
1 Користувач натискає кнопку експорту та надсилає повідомлення
46
ЧДТУ 262265.026 ПЗ
(exportResults) до головного вікна.
Рисунок 2.11 – Діаграма послідовності формування та експорту звіту
47
ЧДТУ 262265.026 ПЗ
2 Головне вікно передає запит до модуля експорту через повідомлення
(generateReport).
3 Модуль експорту надсилає запит (fetchResults) до бази даних для
отримання результатів поточної сесії.
4 База даних повертає структуровані дані (sessionData) модулю експорту.
5 Модуль експорту формує звіт у обраному форматі (HTML, JSON, CSV
або TXT) та повертає шлях до файлу (filePath) головному вікну.
6 Головне вікно інформує користувача про успішне завершення експорту.
Діаграма послідовності дозволяє зрозуміти хронологію взаємодії між
об'єктами системи та є особливо корисною при визначенні порядку викликів між
компонентами. Розбиття на дві окремі діаграми – за функціональними блоками
сканування та експорту – спрощує реалізацію в коді, дозволяє ізолювати класи в
окремі модулі та знизити кількість помилок при розробці. При цьому діаграми
залишаються взаємопов'язаними через спільний компонент бази даних, що є
центральним сховищем даних системи.
2.5.3. Діаграма комунікації
Діаграма комунікації зображена на рисунку 2.12. Опис складається з
декількох частин та представлений описом об'єктів і їх взаємодій.
Об'єкти:
– mainWindow: MainWindow – головне вікно програмного комплексу,
через яке користувач взаємодіє із системою;
– scanThread: ScanThread – потік сканування, що відповідає за запуск
аналізу в окремому потоці виконання;
– taskManager: TaskManager – менеджер задач, який координує роботу
модулів та керує конвеєром сканування;
– scanningModules: BaseModule – узагальнений об'єкт, що представляє
модулі аналізу (SubdomainEnumerationModule, DNSResolverModule,
HTTPXModule, NmapModule, VulnerabilityScannerModule);
– database: Database – база даних, що забезпечує збереження результатів
сканування та управління сесіями;
48
ЧДТУ 262265.026 ПЗ
– exportModule: ExportModule – модуль експорту, відповідальний за
формування підсумкових звітів.
Взаємодія при запуску сканування:
– mainWindow надсилає повідомлення startScan до scanThread;
– scanThread надсилає повідомлення initialize до taskManager;
– taskManager надсилає повідомлення createSession до database для
реєстрації нової сесії сканування;
– database повертає підтвердження sessionCreated до taskManager.
Рисунок 2.12 – Діаграма комунікації
Взаємодія під час виконання модулів:
– taskManager послідовно надсилає повідомлення run до scanningModules;
49
ЧДТУ 262265.026 ПЗ
– кожен модуль після завершення роботи надсилає повідомлення
saveResults до database для збереження отриманих даних;
– database повертає підтвердження збереження resultsSaved до taskManager;
– taskManager надсилає повідомлення updateLog до scanThread, який через
механізм сигналів pyqtSignal передає logMessage до mainWindow для
відображення поточного стану виконання.
Взаємодія під час формування звіту:
– після завершення всіх етапів сканування mainWindow надсилає
повідомлення exportResults до exportModule;
– exportModule надсилає повідомлення fetchResults до database для
отримання результатів поточної сесії;
– database повертає структуровані дані sessionData до exportModule;
– exportModule формує підсумковий звіт та надсилає повідомлення
reportReady до mainWindow;
– mainWindow відображає користувачу повідомлення про успішне
завершення експорту.
2.5.4. Діаграма скінченного автомату
Одним із етапів проектування є створення діаграми скінченного автомату
(діаграма станів). Оскільки складність діаграми напряму залежить від кількості
класів та складності системи, важливим кроком є розділення діаграми на складові
частини. А саме: діаграма станів графічного інтерфейсу користувача
(MainWindow), менеджера задач (TaskManager) та модуля пошуку вразливостей
(VulnerabilityScannerModule). Спроектуємо діаграму (рисунок 2.13) та опишемо
першу частину.
Стани:
– ініціалізовано (Initialized) – стан представляє момент запуску
програмного комплексу, коли графічний інтерфейс готовий до взаємодії
з користувачем;
50
ЧДТУ 262265.026 ПЗ
Рисунок 2.13 – Діаграма станів графічного інтерфейсу користувача
– очікування введення (WaitingForInput) – інтерфейс знаходиться в режимі
очікування, коли користувач має ввести адресу цільового web-ресурсу та
розпочати процес сканування;
– стан сканування (ScanningState) – активується після запуску процесу
аналізу. Відображається журнал виконання задач у режимі реального
часу, а елементи керування переходять у заблокований стан;
51
ЧДТУ 262265.026 ПЗ
– стан помилки (ErrorState) – активується у разі некоректного введення
адреси ресурсу або критичної помилки під час виконання модулів.
Відображається інформаційне повідомлення з описом причини збою;
– відображення результатів (ResultsState) – стан, що активується після
успішного завершення всіх етапів сканування. Вкладки результатів
заповнюються отриманими даними;
– експорт звіту (ExportState) – стан, у якому система формує підсумковий
звіт у обраному форматі та зберігає його на диск.
Переходи:
– зі стану ініціалізовано до очікування введення – перехід відбувається
автоматично після успішного завантаження графічного інтерфейсу;
– з очікування введення до стану сканування – активується після
натискання користувачем кнопки запуску сканування з коректно
введеною адресою ресурсу;
– з очікування введення до стану помилки – відбувається у разі введення
некоректного формату адреси web-ресурсу;
– зі стану сканування до відображення результатів – перехід відбувається
після успішного завершення всіх модулів конвеєра сканування;
– зі стану сканування до стану помилки – активується у разі критичної
помилки під час виконання одного з модулів;
– з відображення результатів до експорту звіту – відбувається після
натискання користувачем кнопки експорту результатів.
Наступним кроком спроектуємо діаграму станів менеджера задач
(рисунок 2.14). Він відіграє ключову роль у координації роботи модулів
сканування та забезпечує коректне переведення між станами конвеєра обробки
даних. Логіка керування станами гарантує, що кожен наступний модуль
запускається лише після успішного завершення попереднього, а результати
передаються між компонентами у структурованому вигляді.
52
ЧДТУ 262265.026 ПЗ
Рисунок 2.14 – Діаграма станів менеджера задач
53
ЧДТУ 262265.026 ПЗ
Стани:
– бездіяльність (Idle) – початковий стан до отримання команди на запуск
сканування;
– створення сесії (CreatingSession) – стан, у якому менеджер задач реєструє
нову сесію сканування у базі даних;
– виконання модулів (RunningModules) – стан активного виконання
конвеєра сканування, під час якого послідовно запускаються всі модулі
аналізу;
– збереження результатів (SavingResults) – стан збереження отриманих
даних до бази даних після завершення роботи кожного модуля;
– завершено (Completed) – стан, що вказує на успішне завершення всіх
етапів сканування;
– помилка виконання (ExecutionError) – стан, що активується у разі збою
під час роботи одного з модулів.
Переходи:
– від бездіяльності до створення сесії – ініціюється після отримання
команди запуску від потоку сканування (ScanThread);
– від створення сесії до виконання модулів – відбувається після успішної
реєстрації сесії у базі даних;
– від виконання модулів до збереження результатів – активується після
завершення роботи кожного окремого модуля;
– від збереження результатів до виконання модулів – відбувається, якщо
конвеєр ще не завершено і наступний модуль очікує на запуск;
– від збереження результатів до завершено – активується після успішного
виконання всіх модулів конвеєра;
– від виконання модулів до помилки виконання – відбувається у разі
критичного збою під час роботи модуля.
Останнім кроком спроектуємо (рисунок 2.15) та опишемо діаграму станів
модуля пошуку вразливостей (VulnerabilityScannerModule).
54
ЧДТУ 262265.026 ПЗ
Рисунок 2.15 – Діаграма станів модуля пошуку вразливостей
Стани:
– очікування (Waiting) – початковий стан, у якому модуль очікує на
отримання даних від попередніх етапів конвеєра (списку відкритих
портів та активних веб-сервісів);
– сканування вразливостей (ScanningVulnerabilities) – стан активного
виконання інструментів аналізу: Nuclei, SQLMap, Searchsploit та Nmap
NSE-скриптів;
55
ЧДТУ 262265.026 ПЗ
– успішно завершено (ScanSuccessful) – стан, що сигналізує про успішне
завершення аналізу та отримання структурованого переліку знайдених
вразливостей;
– помилка сканування (ScanFailed) – стан, що вказує на збій під час
виконання одного з інструментів або відсутність даних для аналізу.
Переходи:
– з очікування до сканування вразливостей – перехід відбувається після
отримання від менеджера задач результатів попередніх модулів;
– зі сканування вразливостей до успішно завершено – активується після
коректного завершення роботи всіх інструментів аналізу та формування
переліку вразливостей;
– зі сканування вразливостей до помилки сканування – відбувається у разі
некоректного завершення роботи зовнішніх інструментів або відсутності
необхідних вхідних даних.
56
ЧДТУ 262265.026 ПЗ
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ
У процесі моделювання предметної області, формування вимог,
проектування логічної структури, архітектурного проектування та моделювання
поведінки системи було отримано цілісне уявлення про архітектуру програмного
комплексу автоматизованого тестування web-ресурсів на вразливість.
Проектування програмного забезпечення є складним і багатоетапним
процесом, що потребує значної уваги від розробника. Проте в довгостроковій
перспективі якісно виконане проектування дозволяє суттєво скоротити час на
реалізацію, зменшити кількість помилок у коді та забезпечити можливість
подальшого розширення функціональності системи.
У ході виконання розділу було розроблено такі проектні артефакти:
– словник предметної області та модель основних доменних об'єктів
системи;
– функціональні та нефункціональні вимоги до програмного комплексу;
– діаграми прецедентів, що визначають сценарії взаємодії користувача із
системою;
– діаграма класів, що відображає структуру компонентів та зв'язки між
ними;
– діаграма пакетів [22], що визначає модульну організацію програмного
комплексу;
– діаграми компонентів та розгортання, що описують фізичну та логічну
архітектуру системи;
– діаграми діяльності, послідовності, комунікації та скінченного автомату,
що моделюють поведінку системи під час виконання основних сценаріїв.
Слід зауважити, що окремі діаграми можуть змінюватись у процесі
реалізації, оскільки спроектувати програмне забезпечення без подальших уточнень
та коригувань практично неможливо. Це відповідає принципам гнучкої
методології розробки Agile [40], яка передбачає ітеративне вдосконалення
продукту, швидке додавання нового функціоналу та адаптацію до змінних вимог.
57
ЧДТУ 262265.026 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу.
3.1.1. Обґрунтування вибору засобів реалізації.
Для реалізації програмного комплексу було обрано мову програмування
Python та графічний фреймворк PyQt6, оскільки вони повністю відповідають як
функціональним, так і нефункціональним вимогам системи. Python є
універсальною мовою програмування, яка широко використовується у галузі
інформаційної безпеки та автоматизації [14]. Завдяки багатій екосистемі бібліотек,
підтримці багатопотоковості та зручній роботі з підпроцесами, Python спрощує
інтеграцію зовнішніх інструментів безпеки, обробку їхнього виводу та збереження
результатів у базу даних. Його модульність дозволяє легко розширювати систему
шляхом додавання нових модулів сканування без зміни загальної архітектури.
PyQt6 було обрано як основу для графічного інтерфейсу завдяки підтримці
багатопотокового виконання через механізм QThread[30], системі сигналів та
слотів (pyqtSignal), що забезпечує оновлення інтерфейсу в режимі реального часу
без його блокування під час сканування. Крім того, PyQt6 надає широкі
можливості для побудови складних інтерфейсів із вкладками, таблицями та
журналом логів [15].
Можливі альтернативи та їхні недоліки.
Мова програмування:
– JavaScript/Node.js. Популярна мова для веб-розробки, проте її екосистема
для роботи із системними підпроцесами та інструментами інформаційної
безпеки значно менш розвинена, ніж у Python. Реалізація конвеєра
сканування була б складнішою та менш ефективною;
– Java. Мова забезпечує високу продуктивність, але її використання для
інтеграції з консольними утилітами безпеки та обробки їхнього виводу
значно складніше через обмежену екосистему відповідних бібліотек;
58
ЧДТУ 262265.026 ПЗ
– Go. Висока швидкодія та підтримка конкурентності, проте значно менша
кількість готових бібліотек для роботи з інструментами кібербезпеки та
обмежені можливості для побудови десктопного GUI.
Фреймворк графічного інтерфейсу:
– Tkinter. Стандартна бібліотека Python для побудови GUI, проте має
обмежені можливості щодо зовнішнього вигляду, відсутність вбудованої
підтримки вкладок та складнішу реалізацію багатопотоковості;
– wxPython. Потужна альтернатива з нативним виглядом на різних
платформах, але значно складніша у налаштуванні та має меншу
спільноту розробників порівняно з PyQt6;
– Electron (HTML/CSS/JS). Дозволяє створювати кросплатформні
десктопні додатки, проте має значно вищі вимоги до ресурсів системи та
ускладнює роботу з підпроцесами Python.
Для збереження результатів сканування обрано СУБД SQLite, оскільки вона
не потребує окремого серверного процесу, повністю інтегрована у стандартну
бібліотеку Python та забезпечує достатню продуктивність для локального
зберігання структурованих результатів сканування.
Можливі альтернативи та їхні недоліки:
– PostgreSQL. Потужна реляційна СУБД, проте вимагає встановлення та
налаштування окремого серверного процесу, що суперечить вимозі
локального розгортання системи без додаткової інфраструктури;
– MongoDB. Документоорієнтована база даних із гнучкою схемою, проте
її використання є надлишковим для структурованих результатів
сканування та вимагає окремого серверного процесу;
– JSON-файли. Простий підхід до збереження результатів, проте не
забезпечує можливості зберігання історії сесій, виконання складних
запитів та ефективного пошуку по результатах попередніх сканувань.
Таким чином, обрані Python, PyQt6 та SQLite надають збалансоване рішення
для розробки програмного комплексу, який потребує інтеграції зовнішніх
інструментів безпеки, зручного графічного інтерфейсу та надійного локального
59
ЧДТУ 262265.026 ПЗ
збереження результатів, що робить їх оптимальним вибором для реалізації вимог
проєкту.
3.1.2. Опис структурної (функціональної) схеми
Структурна схема (рис. 3.1) відображає ключові підсистеми та їх зв'язки в
рамках реалізації програмного комплексу автоматизованого тестування web-
ресурсів на вразливість. Основу системи складає менеджер задач, який взаємодіє з
різними модулями для забезпечення функціональності, визначеної вимогами.
Рисунок 3.1 – Структурна схема
60
ЧДТУ 262265.026 ПЗ
– підсистема графічного інтерфейсу (GUI) забезпечує взаємодію
користувача з програмним комплексом, відображає журнал виконання,
результати сканування у вкладках та надає елементи керування для
запуску і зупинки процесу аналізу;
– підсистема потоку сканування (ScanThread) є посередником між
графічним інтерфейсом і менеджером задач. Її завдання – запускати
процес сканування в окремому потоці виконання та передавати сигнали
про стан виконання до інтерфейсу користувача без його блокування;
– менеджер задач (TaskManager) – основний модуль, який координує
роботу всіх модулів сканування, керує сесіями та забезпечує послідовну
передачу результатів між етапами конвеєра;
– підсистема модулів сканування – забезпечує виконання окремих етапів
аналізу: збір субдоменів, DNS-резолвінг, аналіз веб-сервісів, сканування
портів та пошук вразливостей;
– підсистема зовнішніх інструментів (External Security Tools) – включає
subfinder, assetfinder, crt.sh, httpx, nmap, nuclei[10], sqlmap[11] та
searchsploit[12], які запускаються через механізм підпроцесів та
виконують безпосередній аналіз цільового ресурсу;
– підсистема бази даних (Database) – використовується як централізоване
сховище для збереження результатів сканування, історії сесій та
знайдених вразливостей на основі SQLite;
– підсистема експорту (ExportModule) – відповідає за отримання
результатів із бази даних та формування підсумкових звітів у форматах
HTML[41], JSON[42], CSV[43] та TXT.
Розроблена структурна схема демонструє комплексний підхід до
моделювання програмного комплексу тестування web-ресурсів. Її архітектура є
модульною та легко розширюваною, що дозволяє додавати нові модулі сканування
без зміни загальної структури системи. Використання локальної бази даних SQLite
забезпечує швидкий доступ до результатів без необхідності розгортання
додаткової інфраструктури.
61
ЧДТУ 262265.026 ПЗ
Функціональна схема (рис. 3.2) відображає основні потоки даних і взаємодії
між компонентами системи для реалізації її ключових функцій. Система умовно
поділена на два основні процеси: процес виконання сканування та процес
перегляду результатів і формування звітності.
Процес виконання сканування має наступні функції:
– введення цільового ресурсу. Користувач вводить адресу цільового web-
ресурсу через графічний інтерфейс та ініціює запуск сканування;
– створення сесії. Після запуску система автоматично створює новий запис
сесії у базі даних SQLite для подальшого збереження результатів;
– виконання конвеєра сканування. Менеджер задач послідовно запускає
модулі аналізу, кожен з яких через механізм підпроцесів викликає
відповідні зовнішні інструменти: збір субдоменів за допомогою
subfinder, assetfinder та crt.sh; DNS-резолвінг із фільтрацією Cloudflare IP;
аналіз веб-сервісів через httpx; сканування портів за допомогою nmap;
пошук вразливостей із використанням nuclei, sqlmap, searchsploit та nmap
NSE;
– збереження та відображення результатів. Результати кожного модуля
зберігаються до бази даних та відображаються у відповідних вкладках
графічного інтерфейсу в режимі реального часу через механізм сигналів
pyqtSignal.
Процес перегляду результатів та формування звітності:
– перегляд результатів. Користувач переглядає знайдені субдомени,
відкриті порти та вразливості у відповідних вкладках інтерфейсу після
завершення сканування;
– перегляд історії сесій. Користувач має можливість завантажити
результати попередніх сканувань із бази даних без необхідності
повторного запуску аналізу;
– формування звіту. Модуль експорту отримує дані поточної сесії з бази
даних та формує підсумковий звіт у обраному форматі.
62
ЧДТУ 262265.026 ПЗ
Рисунок 3.2 – Функціональна схема
63
ЧДТУ 262265.026 ПЗ
Запропонована функціональна схема демонструє логіку роботи системи, яка
відповідає її функціональним і нефункціональним вимогам, та забезпечує повний
цикл автоматизованого тестування web-ресурсів – від введення цільового домену
до отримання структурованого звіту.
3.1.3. Опис логічної схеми системи
Система поділяється на два основних алгоритми: алгоритм виконання
сканування та алгоритм перегляду результатів і формування звітності.
Алгоритм виконання сканування
Першим етапом роботи користувача з системою є запуск програмного
комплексу та введення адреси цільового web-ресурсу через графічний інтерфейс.
Після натискання кнопки запуску система перевіряє коректність введених даних.
У разі некоректного формату адреси користувач отримує відповідне повідомлення
про помилку з можливістю повторного введення. Якщо дані коректні, система
створює новий запис сесії у базі даних SQLite та передає керування менеджеру
задач.
Менеджер задач відповідає за послідовний запуск модулів конвеєра
сканування. Першим виконується модуль збору субдоменів, який через механізм
підпроцесів запускає зовнішні інструменти subfinder, assetfinder та crt.sh. Отримані
результати парсяться з формату JSON та зберігаються до бази даних.
Знайдені субдомени передаються модулю DNS-резолвінгу, який перевіряє
активність кожного субдомену та визначає відповідні IP-адреси. На цьому етапі
виконується фільтрація IP-адрес Cloudflare для уникнення сканування чужої
інфраструктури WAF. Результати зберігаються до бази даних та передаються
наступним модулям.
Модуль веб-аналізу отримує список активних субдоменів та запускає
інструмент httpx для визначення доступних HTTP/HTTPS-сервісів, збору
заголовків відповідей та ідентифікації використовуваних технологій. Паралельно
модуль сканування портів запускає nmap для аналізу відкритих мережевих портів
та визначення версій сервісів на унікальних IP-адресах.
Алгоритм сканування комплексу представлено на рисунку 3.3.
64
ЧДТУ 262265.026 ПЗ
Рисунок 3.3 – Логічна схема алгоритму виконання сканування
65
ЧДТУ 262265.026 ПЗ
Завершальним етапом конвеєра є модуль пошуку вразливостей, який
отримує результати попередніх модулів та послідовно запускає інструменти nuclei
для сканування за шаблонами відомих CVE, sqlmap для пошуку SQL-ін'єкцій,
searchsploit для пошуку публічних експлойтів та nmap NSE для аналізу
вразливостей через вбудовані скрипти. Усі знайдені вразливості зберігаються до
бази даних.
Протягом усього процесу сканування менеджер задач через механізм
сигналів pyqtSignal передає повідомлення про поточний стан виконання до
графічного інтерфейсу, який відображає їх у вкладці журналу в режимі реального
часу. Після успішного завершення всіх етапів конвеєра графічний інтерфейс
виконує запити до бази даних та заповнює вкладки результатів – субдомени, порти
та вразливості.
У разі виникнення критичної помилки під час виконання будь-якого модуля
система фіксує помилку у журналі, зберігає частково отримані результати до бази
даних та повідомляє користувача про збій із зазначенням етапу, на якому він
стався.
Алгоритм виконання сканування програмного комплексу представлено у
вигляді блок-схеми на рисунку 3.4.
Алгоритм перегляду результатів та формування звітності
Після завершення сканування користувач може переглядати результати у
відповідних вкладках графічного інтерфейсу. Вкладка субдоменів відображає
знайдені піддомени та їх IP-адреси, вкладка портів – відкриті порти та версії
сервісів, вкладка вразливостей – перелік знайдених загроз із зазначенням рівня
критичності та CVE ID.
Користувач також має можливість завантажити результати попередніх сесій
із панелі історії без необхідності повторного запуску сканування. Система виконує
запит до бази даних та відображає збережені результати обраної сесії.
Для формування звіту користувач натискає кнопку експорту та обирає
бажаний формат. Модуль експорту отримує всі дані поточної сесії з бази даних та
формує підсумковий документ. HTML-звіт містить графіки розподілу
66
ЧДТУ 262265.026 ПЗ
вразливостей, загальну оцінку безпеки ресурсу та детальний опис кожної
знайденої загрози включно з CVE ID та рекомендаціями щодо усунення. Після
успішного формування звіту користувач отримує повідомлення із шляхом до
збереженого файлу.
Алгоритм перегляду результатів та формування звітності зображено на
рисунку 3.4.
Рисунок 3.4 – Логічна схема алгоритму перегляду результатів
67
ЧДТУ 262265.026 ПЗ
3.1.4. Розробка бази даних
У програмному комплексі для організації та зберігання результатів
сканування використано реляційну базу даних SQLite. Цей вибір обумовлений
необхідністю забезпечити структуроване збереження великої кількості
взаємопов'язаних даних, підтримку історії сесій та ефективне виконання запитів
без необхідності розгортання окремого серверного процесу.
Особливістю SQLite є те, що вся база даних зберігається у єдиному файлі на
диску, що спрощує розгортання системи та забезпечує повну портативність
результатів сканування. Такий підхід є оптимальним для локального програмного
комплексу, де не потрібна багатокористувацька робота з даними. Схема бази даних
наведена на рисунку 3.5.
База даних програмного комплексу містить такі таблиці:
– targets – зберігає інформацію про цільові домени. Містить поля:
ідентифікатор запису, адреса домену, дата першого сканування;
– scan_sessions – зберігає інформацію про сесії сканування. Містить поля:
ідентифікатор сесії, зовнішній ключ до таблиці targets, дата та час
початку сканування, дата та час завершення, статус виконання;
– subdomains – зберігає знайдені субдомени. Містить поля: ідентифікатор
запису, зовнішній ключ до scan_sessions, назва субдомену, статус
активності;
– ips – зберігає IP-адреси активних вузлів. Містить поля: ідентифікатор
запису, зовнішній ключ до scan_sessions, зовнішній ключ до subdomains,
IP-адреса, ознака належності до Cloudflare;
– ports – зберігає результати сканування портів. Містить поля:
ідентифікатор запису, зовнішній ключ до scan_sessions, зовнішній ключ
до ips, номер порту, протокол, назва сервісу, версія сервісу, стан порту;
– technologies – зберігає визначені технології веб-сервісів. Містить поля:
ідентифікатор запису, зовнішній ключ до scan_sessions, зовнішній ключ
до subdomains, назва технології, версія, категорія;
– vulnerabilities – зберігає знайдені вразливості. Містить поля:
68
ЧДТУ 262265.026 ПЗ
ідентифікатор запису, зовнішній ключ до scan_sessions, назва
вразливості, CVE ID, рівень критичності, опис, інструмент що виявив
вразливість, цільовий хост.
Рисунок 3.5 – Схема бази даних
Зв'язки між таблицями реалізовано через механізм зовнішніх ключів, що
забезпечує цілісність даних та дозволяє ефективно отримувати повну інформацію
про будь-яку сесію сканування одним запитом.
69
ЧДТУ 262265.026 ПЗ
Усі операції зі створення таблиць, збереження та отримання даних
інкапсульовані у класі Database та реалізовані з використанням стандартної
бібліотеки Python sqlite3[28]. Це забезпечує єдину точку доступу до бази даних для
всіх модулів системи та спрощує подальшу підтримку й розширення схеми даних.
3.1.5. Розробка інтерфейсу користувача
У рамках розробки програмного комплексу графічний інтерфейс
користувача реалізовано з використанням фреймворку PyQt6. Це рішення дозволяє
забезпечити повний контроль над зовнішнім виглядом та поведінкою інтерфейсу,
реалізувати відображення результатів у режимі реального часу та забезпечити
зручну навігацію між розділами програми без необхідності використання
сторонніх платформ.
Головне вікно програмного комплексу (рис. 3.6) складається з таких
елементів:
– поле введення цільового домену – текстове поле для введення адреси
web-ресурсу, що підлягає аналізу;
– кнопки керування – кнопка запуску сканування та кнопка зупинки
процесу, які відповідно ініціюють та переривають виконання конвеєра
аналізу;
– панель історії сесій – відображає перелік попередніх сканувань із
можливістю завантаження їх результатів без повторного запуску аналізу;
– вкладка журналу (Logs) – відображає повідомлення про поточний стан
виконання модулів у режимі реального часу через механізм сигналів
pyqtSignal;
– вкладка субдоменів (Subdomains) – таблиця із переліком знайдених
піддоменів та їх IP-адресами;
– вкладка портів (Ports) – таблиця із результатами сканування відкритих
портів, назвами та версіями сервісів;
– вкладка вразливостей (Vulnerabilities) – таблиця із переліком знайдених
вразливостей, рівнем критичності та CVE ID;
– кнопка експорту результатів – ініціює формування підсумкового звіту в
70
ЧДТУ 262265.026 ПЗ
обраному форматі.
Усі ресурсоємні операції сканування виконуються в окремому потоці
QThread, що унеможливлює блокування графічного інтерфейсу під час роботи
модулів аналізу. Зв'язок між потоком сканування та інтерфейсом забезпечується
через механізм сигналів та слотів PyQt6[29], що гарантує безпечне оновлення
елементів інтерфейсу з окремого потоку виконання.
Рисунок 3.6 – Головне вікно програмного комплексу
71
ЧДТУ 262265.026 ПЗ
Рисунок 3.7 – Вкладка результатів сканування
Інтерфейс забезпечує інтуїтивно зрозумілий користувацький досвід –
користувачу достатньо ввести домен та натиснути одну кнопку для запуску
повного циклу автоматизованого тестування. Завдяки такому підходу програмний
комплекс є доступним як для досвідчених спеціалістів з інформаційної безпеки,
так і для користувачів із базовими технічними знаннями.
3.1.6. Опис розробки програмних компонентів
Основні реалізовані модулі програмного комплексу (рис. 3.8): модуль
графічного інтерфейсу, модуль менеджера задач, модулі сканування, модуль бази
даних та модуль експорту результатів.
72
ЧДТУ 262265.026 ПЗ
Рисунок 3.8 – Файлова структура проєкту
Файлова структура проєкту організована таким чином:
– src/gui/main_window.py – головне вікно програмного комплексу та потік
сканування;
– src/core/task_manager.py – менеджер задач, що координує роботу
модулів;
– src/modules/subdomain_enumeration.py – модуль збору субдоменів;
– src/modules/dns_resolver.py – модуль DNS-резолвінгу;
– src/modules/httpx_module.py – модуль веб-аналізу;
– src/modules/nmap_module.py – модуль сканування портів;
– src/modules/vulnerability_scanner.py – модуль пошуку вразливостей;
– src/database/database.py – модуль роботи з базою даних SQLite;
– src/utils/export.py – модуль експорту результатів.
Базовий клас модулів BaseModule визначає загальний інтерфейс для всіх
модулів сканування. Він містить методи run, parse_output та save_to_db, які кожен
73
ЧДТУ 262265.026 ПЗ
модуль успадковує та перевизначає згідно зі специфікою інструменту, що
використовується. Повний лістинг класу наведено у додатку А.
Модуль TaskManager містить метод execute, який послідовно запускає
модулі конвеєра та передає результати між ними. Після завершення роботи
кожного модуля результати зберігаються до бази даних та передаються
наступному модулю як вхідні дані. Повний лістинг наведено у додатку А.
Модуль збору субдоменів SubdomainEnumerationModule реалізує запуск
трьох зовнішніх інструментів через механізм підпроцесів Python – subfinder,
assetfinder та crt.sh. Отримані результати об'єднуються та очищуються від
дублікатів перед передачею до наступного модуля конвеєра. Повний лістинг
наведено у додатку А.
Модуль пошуку вразливостей VulnerabilityScannerModule є найбільш
складним компонентом системи, оскільки інтегрує чотири інструменти аналізу:
nuclei для сканування за шаблонами відомих CVE, sqlmap для автоматичного
пошуку SQL-ін'єкцій, searchsploit для пошуку публічних експлойтів та nmap NSE
для аналізу вразливостей через вбудовані скрипти. Повний лістинг наведено у
додатку А.
Модуль експорту ExportModule містить кілька сталих змінних,
налаштування яких визначає формат та структуру звітів:
– REPORT_TEMPLATE_PATH – шлях до HTML-шаблону звіту;
– SEVERITY_COLORS – словник кольорового маркування рівнів
критичності вразливостей (critical, high, medium, low, info);
– EXPORT_DIR – шлях до директорії збереження згенерованих звітів;
– DATE_FORMAT – формат дати та часу у назві файлу звіту.
Метод export_html отримує дані сесії з бази даних та формує повноцінний
HTML-звіт із графіками розподілу вразливостей та детальним описом кожної
знайденої загрози включно з CVE ID. Повний лістинг наведено у додатку А.
Таким чином, реалізація програмного комплексу має модульну архітектуру,
вирішує усі поставлені функціональні та нефункціональні вимоги та надає повний
функціонал автоматизованого тестування web-ресурсів на вразливість.
74
ЧДТУ 262265.026 ПЗ
3.2. Тестування системи
У розробці будь-якого програмного забезпечення тестування є одним з
найважливіших етапів. Метою цього процесу є виявлення та подальше
виправлення помилок, забезпечення відповідності програмного продукту
визначеним вимогам і забезпечення його надійності та стабільності в умовах
реального використання.
Тестування використовують для перевірки різних аспектів програмного
комплексу, включаючи:
1 Перевірка функціональності – допомагає забезпечити правильність
виконання усіх функцій відповідно до специфікації та вимог
користувача.
2 Оцінка продуктивності – допомагає визначити, наскільки ефективно
система працює під різним навантаженням, швидкість обробки запитів,
витрати ресурсів.
3 Перевірка надійності – тестування стабільності роботи системи при
тривалому виконанні та обробці великих обсягів даних.
4 Об'єктом тестування у цьому проєкті є програмний комплекс
автоматизованого тестування web-ресурсів на вразливість, який реалізує
збір субдоменів, DNS-резолвінг, аналіз веб-сервісів, сканування портів,
пошук вразливостей та формування звітності.
Щоб успішно протестувати розроблений програмний комплекс і забезпечити
його стабільну роботу, застосовуватиметься послідовний і поетапний підхід до
проведення тестування. Кожен етап включає визначення обсягу тестування, вибір
конкретної стратегії та формування переліку тестових випадків. Після виконання
кожного етапу тестування буде проведено аналіз отриманих результатів для
виявлення можливих недоліків.
У наступних підрозділах розглянуто кілька підходів до тестування
розробленого програмного комплексу, а також окреслено особливості їх
застосування в контексті реалізованої архітектури.
75
ЧДТУ 262265.026 ПЗ
3.2.1. Модульне тестування
Обсяг тестування
Модульне тестування включає перевірку окремих логічних частин
програмного комплексу, зокрема модулів збору субдоменів, DNS-резолвінгу,
роботи з базою даних та пошуку вразливостей. Таким чином, тестуються такі
модулі:
– database – модуль роботи з базою даних SQLite. Перевіряється
коректність створення сесії, збереження та отримання результатів
сканування;
– subdomain_enumeration – модуль збору субдоменів. Перевіряється
правильність парсингу результатів інструментів subfinder, assetfinder та
crt.sh, а також усунення дублікатів;
– dns_resolver – модуль DNS-резолвінгу. Перевіряється коректність
визначення активних субдоменів та фільтрація Cloudflare IP-адрес[31];
– vulnerability_scanner – модуль пошуку вразливостей. Перевіряється
коректність парсингу результатів nuclei та правильність визначення рівня
критичності знайдених вразливостей;
– export – модуль експорту результатів. Перевіряється коректність
формування звітів у форматах HTML, JSON, CSV та TXT.
Стратегія тестування
У ході тестування перевіряються виклики основних функцій із
використанням тестових даних, щоб переконатися у правильності їх роботи. Для
модулів, що взаємодіють із зовнішніми інструментами, використовуються mock-
об'єкти бібліотеки unittest.mock[14], що дає змогу емулювати виклики
subprocess[27] без реального запуску subfinder, nmap, nuclei та інших утиліт. Це
значно пришвидшує виконання тестів та унеможливлює залежність результатів
тестування від наявності встановлених інструментів та мережевого з'єднання.
Тестові файли розміщено у папці tests та запускаються командою pytest[26]
tests/ у кореневій папці проєкту.
Тестові випадки
76
ЧДТУ 262265.026 ПЗ
Таблиця 3.1
Тестовий випадок модульного тестування №1
Тест-кейс №1
Опис Створення сесії сканування у базі даних
Передумови Ініціалізовано тимчасовий екземпляр класу Database з
базою даних у пам'яті
Кроки 1. Виклик методу create_session("example.com"). 2.
Перевірка повернутого session_id.
Очікуваний результат Метод повертає ціле число session_id більше нуля
Фактичний результат Метод повертає ціле число session_id більше нуля
Пройдено Так
Таблиця 3.2
Тестовий випадок модульного тестування №2
Тест-кейс №2
Опис Парсинг результатів модуля збору субдоменів
Передумови Підготовлено mock-відповідь у форматі JSON від
subfinder
Кроки 1. Виклик методу parse_output() з тестовими даними. 2.
Перевірка отриманого списку субдоменів.
Очікуваний результат Метод повертає список унікальних субдоменів без
дублікатів
Фактичний результат Метод повертає список унікальних субдоменів без
дублікатів
Пройдено Так
Таблиця 3.3
Тестовий випадок модульного тестування №3
Тест-кейс №3
Опис Фільтрація Cloudflare IP-адрес у модулі DNS-
резолвінгу
Передумови Підготовлено список IP-адрес що містить Cloudflare та
звичайні адреси
77
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.3
Кроки 1. Виклик методу filter_cloudflare(ip_list). 2. Перевірка
результуючого списку.
Очікуваний результат Метод повертає список IP-адрес без Cloudflare
діапазонів
Фактичний результат Метод повертає список IP-адрес без Cloudflare
діапазонів
Пройдено Так
Таблиця 3.4
Тестовий випадок модульного тестування №4
Тест-кейс №4
Опис Визначення рівня критичності вразливості у модулі
пошуку вразливостей
Передумови Підготовлено mock-відповідь nuclei з вразливістю
рівня critical
Кроки 1. Виклик методу parse_output() з тестовими даними
nuclei. 2. Перевірка поля severity у результаті.
Очікуваний результат Поле severity містить значення "critical"
Фактичний результат Поле severity містить значення "critical"
Пройдено Так
Таблиця 3.5
Тестовий випадок модульного тестування №5
Тест-кейс №5
Опис Генерація HTML-звіту модулем експорту
Передумови У базі даних збережено тестові результати сканування
Кроки 1. Виклик методу export_html(session_id). 2. Перевірка
існування згенерованого файлу.
Очікуваний результат HTML-файл успішно створено у директорії експорту
Фактичний результат HTML-файл успішно створено у директорії експорту
Пройдено Так
78
ЧДТУ 262265.026 ПЗ
Аналіз проведеного тестування
У ході цього етапу тестування було проведено перевірку основних
функціональних модулів програмного комплексу, зокрема роботи з базою даних,
збору субдоменів, DNS-резолвінгу, пошуку вразливостей та експорту результатів.
До початку безпосереднього тестування було детально визначено обсяг перевірки,
сформовано загальну стратегію тестування та розроблено набір тестових випадків
для покриття ключових сценаріїв використання.
Усі створені тести було виконано успішно. Це підтвердило відповідність
реалізації поставленим вимогам та забезпечує надійність функціонування
програмного комплексу. Враховуючи успішне проходження тестів без критичних
зауважень, цей етап тестування можна вважати повністю завершеним.
3.2.2. Інтеграційне тестування
Обсяг тестування
Для інтеграційного тестування було проведено перевірку взаємодії всіх
модулів програмного комплексу. Метою даного тестування є перевірка коректної
взаємодії між окремими компонентами системи, а також відповідності результатів
очікуваним значенням. Основні функції, які були протестовані:
– запуск повного конвеєра сканування та передача даних між модулями;
– збереження результатів кожного модуля до бази даних SQLite;
– коректність передачі субдоменів від модуля збору до модуля DNS-
резолвінгу;
– коректність передачі IP-адрес до модулів сканування портів та веб-
аналізу;
– передача результатів до модуля експорту та генерація звіту.
Стратегія тестування
Для цього тестування була використана стратегія Big Bang Integration
Testing. У межах цієї стратегії всі модулі – збір субдоменів, DNS-резолвінг, веб-
аналіз, сканування портів, пошук вразливостей, база даних та експорт – були
інтегровані одночасно, після чого проведено тестування усієї системи як єдиного
цілого на реальному тестовому домені. Перевагою цього підходу є можливість
79
ЧДТУ 262265.026 ПЗ
швидко отримати повну картину роботи системи та перевірити коректність
передачі даних між усіма модулями конвеєра.
Тестові випадки
Таблиця 3.6
Тестовий випадок інтеграційного тестування №1
Тест-кейс №1
Опис Запуск повного циклу сканування та створення сесії
Передумови Програмний комплекс запущено, введено адресу
тестового домену
Кроки 1. Натиснути кнопку запуску сканування. 2.
Перевірити створення запису сесії у базі даних.
Очікуваний результат У базі даних створено новий запис у таблиці
scan_sessions із коректним session_id
Фактичний результат У базі даних створено новий запис у таблиці
scan_sessions із коректним session_id
Пройдено Так
Таблиця 3.7
Тестовий випадок інтеграційного тестування №2
Тест-кейс №2
Опис Передача субдоменів від модуля збору до модуля DNS-
резолвінгу
Передумови Модуль збору субдоменів завершив роботу
Кроки 1. Перевірити збереження субдоменів у таблиці
subdomains. 2. Перевірити що модуль DNS-резолвінгу
отримав список субдоменів.
Очікуваний результат Модуль DNS-резолвінгу отримує повний список
субдоменів та визначає їх IP-адреси
80
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.7
Фактичний результат Модуль DNS-резолвінгу отримує повний список
субдоменів та визначає їх IP-адреси
Пройдено Так
Таблиця 3.8
Тестовий випадок інтеграційного тестування №3
Тест-кейс №3
Опис Передача IP-адрес до модулів сканування портів та
веб-аналізу
Передумови Модуль DNS-резолвінгу завершив роботу та зберіг IP-
адреси
Кроки 1. Перевірити що модуль NmapModule отримав список
IP-адрес. 2. Перевірити що модуль HTTPXModule
отримав список субдоменів.
Очікуваний результат Обидва модулі отримують коректні вхідні дані та
виконують сканування
Фактичний результат Обидва модулі отримують коректні вхідні дані та
виконують сканування
Пройдено Так
Таблиця 3.9
Тестовий випадок інтеграційного тестування №4
Тест-кейс №4
Опис Збереження результатів сканування портів до бази
даних
Передумови Модуль NmapModule завершив сканування
Кроки 1. Перевірити наявність записів у таблиці ports. 2.
Перевірити коректність полів port_number,
service_name, service_version.
81
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.9
Очікуваний результат Таблиця ports містить коректні записи з результатами
сканування
Фактичний результат Таблиця ports містить коректні записи з результатами
сканування
Пройдено Так
Таблиця 3.10
Тестовий випадок інтеграційного тестування №5
Тест-кейс №5
Передача результатів до модуля експорту та генерація
HTML-звіту
Передумови Всі модулі конвеєра завершили роботу, результати
збережено до бази даних
Кроки 1. Натиснути кнопку експорту результатів. 2.
Перевірити наявність згенерованого HTML-файлу. 3.
Перевірити наявність даних про вразливості у звіті.
Очікуваний результат HTML-звіт успішно згенеровано та містить повні
результати сканування
Фактичний результат HTML-звіт успішно згенеровано та містить повні
результати сканування
Пройдено Так
Аналіз проведеного тестування
Як можна побачити, усі тести були виконані успішно. Це свідчить про те, що
у всіх визначених тестових випадках отримано результат, який відповідає
очікуванням.
Таким чином, можна зробити висновок, що інтеграційне тестування за
стратегією Big Bang завершено успішно. Усі модулі конвеєра коректно
взаємодіють між собою, дані передаються без втрат, а результати зберігаються до
82
ЧДТУ 262265.026 ПЗ
бази даних у відповідному форматі.
3.2.3. Системне тестування
Обсяг тестування
У системному тестуванні охоплюються всі компоненти програмного
комплексу після їх інтеграції, що дозволяє протестувати роботу всієї системи в
цілому. Цей вид тестування забезпечує ретельну перевірку на відповідність
системи визначеним функціональним та нефункціональним вимогам. Метою
такого тестування є виявлення дефектів, що можуть виникнути при взаємодії
окремих модулів чи частин системи. Перевіряється взаємодія графічного
інтерфейсу, менеджера задач, модулів сканування, бази даних та модуля експорту
в умовах реального використання.
Стратегія тестування
Для перевірки роботи системи використовується підхід наскрізного
тестування – запуск повного циклу сканування реального тестового домену з
перевіркою коректності виконання кожного етапу конвеєра та отриманих
результатів. Перевірка взаємодії між модулями проводиться шляхом аналізу
журналу виконання, вмісту бази даних після завершення сканування та
згенерованого HTML-звіту. Це дозволяє переконатись, що всі основні модулі
працюють узгоджено.
Тестові випадки
Таблиця 3.11
Тестовий випадок системного тестування №1
Тест-кейс №1
Опис Запуск повного циклу сканування тестового домену
Передумови Програмний комплекс запущено, всі зовнішні
інструменти встановлено
Кроки 1. Ввести адресу тестового домену. 2. Натиснути
кнопку запуску сканування. 3. Дочекатися
завершення всіх етапів конвеєра.
83
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.11
Очікуваний результат Всі п'ять модулів конвеєра виконано успішно,
результати відображено у вкладках інтерфейсу
Фактичний результат Всі п'ять модулів конвеєра виконано успішно,
результати відображено у вкладках інтерфейсу
Пройдено Так
Таблиця 3.12
Тестовий випадок системного тестування №2
Тест-кейс №2
Опис Перевірка стабільності графічного інтерфейсу під час
сканування
Передумови Запущено процес сканування
Кроки 1. Під час виконання сканування взаємодіяти з
елементами інтерфейсу. 2. Перевірити відсутність
зависань та блокувань.
Очікуваний результат Графічний інтерфейс залишається responsive, журнал
оновлюється в реальному часі
Фактичний результат Графічний інтерфейс залишається responsive, журнал
оновлюється в реальному часі
Пройдено Так
Таблиця 3.13
Тестовий випадок системного тестування №3
Тест-кейс №3
Опис Перевірка збереження результатів та завантаження
історії сесій
Передумови Сканування успішно завершено
Кроки 1. Перезапустити програму. 2. Відкрити панель історії
сесій. 3. Завантажити результати попереднього
сканування.
84
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.13
Очікуваний результат Результати попереднього сканування коректно
відображаються у вкладках інтерфейсу
Фактичний результат Результати попереднього сканування коректно
відображаються у вкладках інтерфейсу
Пройдено Так
Таблиця 3.14
Тестовий випадок системного тестування №4
Тест-кейс №4
Опис Генерація звітів у всіх підтримуваних форматах
Передумови Сканування успішно завершено, результати збережено до
бази даних
Кроки 1. Натиснути кнопку експорту. 2. Почергово обрати формати
HTML, JSON, CSV, TXT. 3. Перевірити вміст кожного файлу.
Очікуваний Звіти у всіх чотирьох форматах успішно згенеровано та
результат містять повні результати сканування
Фактичний Звіти у всіх чотирьох форматах успішно згенеровано та
результат містять повні результати сканування
Пройдено Так
Таблиця 3.15
Тестовий випадок системного тестування №5
Тест-кейс №5
Опис Перевірка коректності введення некоректної адреси
домену
Передумови Програмний комплекс запущено
Кроки 1. Ввести некоректну адресу домену. 2. Натиснути кнопку
запуску сканування.
Очікуваний Система відображає повідомлення про помилку та не
результат запускає сканування
85
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.15
Фактичний Система відображає повідомлення про помилку та не
результат запускає сканування
Пройдено Так
3.2.4. Приймальне тестування
Обсяг тестування
Приймальне тестування охоплює всі функціональні та нефункціональні
вимоги до програмного комплексу автоматизованого тестування web-ресурсів на
вразливість, що були визначені у розділі формування вимог. Мета цього
тестування полягає у тому, щоб переконатись у відповідності розробленого
продукту всім визначеним на етапі проєктування вимогам.
Стратегія тестування
На першому етапі детально проаналізовано всі вимоги до готового продукту
та визначено перелік вимог, що перевірятимуться під час цього тестування. Після
визначення переліку вимог розроблено детальний чеклист та послідовно виконано
усі тестові випадки. У кінці тестування проаналізовано результати та підбито
підсумок.
Проведення тестування
Для початку розглянемо вимоги, які були визначені на етапі проєктування та
які слід перевірити:
Для користувача:
– введення адреси цільового web-ресурсу та запуск сканування;
– перегляд результатів сканування у вкладках субдоменів, портів та
вразливостей;
– перегляд журналу виконання в режимі реального часу;
– завантаження результатів попередніх сесій з панелі історії;
– експорт результатів у форматах HTML, JSON, CSV та TXT;
– отримання повідомлення про помилку при некоректному введенні
домену.
86
ЧДТУ 262265.026 ПЗ
Для розробника (через внутрішню перевірку бази даних):
– перевірка коректності збереження результатів до бази даних SQLite;
– перевірка послідовності виконання модулів конвеєра;
– коректна логіка передачі даних між модулями.
Тестові випадки
Таблиця 3.16
Тестовий випадок приймального тестування №1
Тест-кейс №1
Опис Введення адреси цільового домену та запуск сканування
Кроки 1. Ввести коректну адресу домену у текстове поле. 2.
Натиснути кнопку запуску сканування.
Очікуваний Сканування успішно запускається, у журналі з'являються
результат повідомлення про роботу модулів
Пройдено Так
Таблиця 3.17
Тестовий випадок приймального тестування №2
Тест-кейс №2
Опис Перевірка відображення результатів у вкладках інтерфейсу
Кроки 1. Дочекатися завершення сканування. 2. Перевірити
вкладки субдоменів, портів та вразливостей.
Очікуваний Всі три вкладки заповнені результатами сканування
результат
Пройдено Так
Таблиця 3.18
Тестовий випадок приймального тестування №3
Тест-кейс №3
Опис Завантаження результатів попередньої сесії з панелі історії
87
ЧДТУ 262265.026 ПЗ
Продовження таблиці 3.18
Кроки 1. Перезапустити програму. 2. Обрати попередню сесію з
панелі історії. 3. Перевірити відображення результатів.
Очікуваний Результати попередньої сесії коректно завантажуються та
результат відображаються у вкладках
Пройдено Так
Таблиця 3.19
Тестовий випадок приймального тестування №4
Тест-кейс №4
Опис Експорт результатів у форматі HTML
Кроки 1. Після завершення сканування натиснути кнопку експорту.
2. Обрати формат HTML. 3. Відкрити згенерований файл у
браузері.
Очікуваний HTML-звіт містить графіки розподілу вразливостей, загальну
результат оцінку безпеки та детальний опис знайдених загроз з CVE ID
Пройдено Так
Таблиця 3.20
Тестовий випадок приймального тестування №5
Тест-кейс №5
Опис Перевірка обробки некоректного введення домену
Кроки 1. Ввести некоректну адресу домену. 2. Натиснути кнопку
запуску сканування.
Очікуваний Система відображає повідомлення про помилку та не
результат запускає сканування
Пройдено Так
88
ЧДТУ 262265.026 ПЗ
Таблиця 3.21
Тестовий випадок приймального тестування №6
Тест-кейс №6
Опис Перевірка стабільності роботи під час тривалого сканування
Кроки 1. Запустити сканування великого домену. 2. Спостерігати за
роботою інтерфейсу протягом усього процесу.
Очікуваний Графічний інтерфейс не блокується, журнал оновлюється в
результат реальному часі, сканування завершується успішно
Пройдено Так
Аналіз проведеного тестування
Проаналізувавши вимоги, які були визначені на етапі проєктування, було
складено перелік тестових випадків, необхідних для перевірки на відповідність
вимогам. Відтворивши усі сценарії, переконались у тому, що усі визначені вимоги
задоволені та успішно проходять тестування. Приймальне тестування можна
вважати успішним – програмний комплекс готовий до використання.
Однак під час тестування було виявлено кілька аспектів, що потребують
подальшого вдосконалення. По-перше, час виконання повного циклу сканування
суттєво залежить від кількості знайдених субдоменів та відкритих портів. По-
друге, модуль sqlmap потребує додаткового налаштування параметрів для
зменшення кількості хибнопозитивних результатів. Розширення функціоналу
системи шляхом додавання можливості паралельного виконання модулів суттєво
підвищило б її ефективність.
3.3. Приклади впровадженого програмного комплексу
У цьому підрозділі наведено приклади роботи впровадженого програмного
комплексу автоматизованого тестування веб-ресурсів Pentest-Tool.
Продемонстровано основні сценарії взаємодії користувача із системою, зокрема
запуск сканування, виконання збору інформації, перегляд результатів аналізу та
формування звітів. Наведені приклади дозволяють оцінити функціональність
89
ЧДТУ 262265.026 ПЗ
системи, зручність використання та відповідність розробленого програмного
забезпечення поставленим вимогам.
Після запуску програмного комплексу користувач потрапляє до головного
вікна системи (рис. 3.9), яке містить основні елементи керування процесом
сканування. У верхній частині інтерфейсу розміщено поле введення цільового
домену та кнопки запуску і зупинки сканування.
Для початку роботи користувачу необхідно ввести доменне ім'я або адресу
веб-ресурсу та натиснути кнопку запуску сканування. Після цього система створює
нову сесію аналізу та запускає автоматизований процес збору інформації.
Під час виконання сканування програма послідовно виконує окремі модулі
аналізу, а результати їхньої роботи відображаються у вкладці журналу подій у
режимі реального часу (рис. 3.10).
Рисунок 3.9 – Головне вікно програмного комплексу
90
ЧДТУ 262265.026 ПЗ
Рисунок 3.10 – Відображення процесу сканування
Далі програма автоматично виконує аналіз HTTP-сервісів, визначення
технологій веб-ресурсу та сканування відкритих портів із використанням Nmap
(рис. 3.11).
Рисунок 3.11 – Вкладка результатів сканування
91
ЧДТУ 262265.026 ПЗ
Після завершення основних етапів аналізу система запускає модуль пошуку
вразливостей. Для цього використовуються інструменти Nuclei, SQLMap,
Searchsploit та NSE-скрипти Nmap.
Результати сканування автоматично зберігаються у базі даних SQLite та
відображаються у вкладках «Субдомени», «Порти» та «Вразливості» (рис. 3.12).
Рисунок 3.12 – Перегляд знайдених результатів
Після завершення аналізу користувач може скористатися функцією експорту
результатів. Система підтримує формування звітів у форматах JSON, CSV, TXT та
HTML (рис. 3.13).
Рисунок 3.13 – Експорт результатів сканування
92
ЧДТУ 262265.026 ПЗ
Розроблений інтерфейс забезпечує зручну взаємодію користувача із
системою та дозволяє контролювати весь процес тестування без необхідності
ручного запуску окремих інструментів.
93
ЧДТУ 262265.026 ПЗ
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
У розділі детально розглянуто основні аспекти розробки та тестування
програмного комплексу автоматизованого тестування web-ресурсів на вразливість.
Обґрунтовано вибір засобів реалізації – мови програмування Python, фреймворку
PyQt6 та бази даних SQLite. Описано структурну та функціональну схеми системи,
логіку роботи конвеєра сканування та архітектуру основних програмних
компонентів. Розроблено схему бази даних із сімома взаємопов'язаними
таблицями для зберігання повної історії сканувань.
Проведено модульне, інтеграційне, системне та приймальне тестування,
результати якого підтвердили коректність роботи всіх компонентів системи.
Наведено приклади роботи програмного комплексу з реальним тестовим доменом,
що демонструють повний цикл автоматизованого аналізу – від введення цільового
домену до отримання структурованого HTML-звіту.
Розділ дозволяє наочно переконатися у функціональності та практичності
реалізованого програмного комплексу, підтверджуючи його відповідність
поставленим вимогам і зручність у використанні.
94
ЧДТУ 262265.026 ПЗ
ВИСНОВКИ
У кваліфікаційній роботі розв'язано актуальну науково-практичну задачу
розробки програмного забезпечення для автоматизації процесу тестування web-
ресурсів на вразливість, що об'єднує популярні інструменти інформаційної
безпеки в єдиний автоматизований конвеєр із графічним інтерфейсом користувача.
Для досягнення поставленої мети були визначені такі завдання: провести
аналіз існуючих методів та засобів тестування безпеки веб-ресурсів; дослідити
сучасні інструменти для пошуку субдоменів, сканування мережевої
інфраструктури та аналізу вразливостей; виконати моделювання предметної
області та сформувати вимоги до програмного забезпечення; розробити
архітектуру програмного комплексу з використанням модульного підходу;
реалізувати механізм автоматизованої взаємодії між модулями на основі
конвеєрної обробки даних; реалізувати графічний інтерфейс користувача;
забезпечити збереження результатів у базі даних; реалізувати механізм
формування звітів; провести тестування розробленого програмного забезпечення.
На основі вирішення поставлених завдань отримано такі результати:
− проведено аналіз існуючих методів та засобів тестування безпеки веб-
ресурсів, досліджено інструменти subfinder, assetfinder, httpx, nmap,
nuclei, sqlmap та searchsploit, встановлено що традиційний підхід із
ручним використанням окремих інструментів є трудомістким і потребує
значних часових витрат;
− виконано моделювання предметної області, сформовано функціональні
та нефункціональні вимоги, побудовано комплект UML-діаграм:
варіантів використання, класів, пакетів, компонентів, розгортання,
діяльності, послідовності, комунікації та скінченного автомату;
− розроблено модульну архітектуру програмного комплексу на основі
патерну «Оркестратор», що забезпечує автоматизовану передачу даних
між модулями конвеєра та дозволяє розширювати функціональність
системи без зміни її загальної структури;
95
ЧДТУ 262265.026 ПЗ
− реалізовано конвеєр сканування що включає п'ять послідовних етапів:
збір субдоменів із використанням subfinder, assetfinder та crt.sh, DNS-
резолвінг з фільтрацією Cloudflare IP, аналіз веб-сервісів через httpx,
сканування портів за допомогою nmap та пошук вразливостей із
застосуванням nuclei, sqlmap, searchsploit та nmap NSE;
− реалізовано графічний інтерфейс користувача на базі PyQt6 із журналом
подій у режимі реального часу, вкладками результатів та механізмом
керування процесом сканування;
− розроблено реляційну схему бази даних SQLite із сімома
взаємопов'язаними таблицями для централізованого збереження повної
історії сканувань та забезпечення повторного використання результатів;
− реалізовано модуль експорту результатів у форматах HTML, JSON, CSV
та TXT, де HTML-звіт містить графіки розподілу вразливостей, загальну
оцінку безпеки ресурсу та детальний опис знайдених загроз включно з
CVE ID;
− проведено модульне, інтеграційне, системне та приймальне тестування,
результати якого підтвердили відповідність реалізації всім
функціональним і нефункціональним вимогам.
Практична цінність роботи полягає у тому, що розроблений програмний
комплекс дозволяє суттєво скоротити час проведення розвідки та пошуку
вразливостей web-ресурсів порівняно з ручним використанням окремих
інструментів, а також забезпечує автоматичне формування структурованої
звітності для подальшого аналізу фахівцями з інформаційної безпеки.
Перспективами подальшого розвитку програмного комплексу є реалізація
паралельного виконання модулів конвеєра для скорочення загального часу
сканування, розширення переліку інтегрованих інструментів, додавання
підтримки сканування за розкладом та розробка веб-інтерфейсу для забезпечення
багатокористувацького режиму роботи.
96
ЧДТУ 262265.026 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 OWASP Top Ten. The Ten Most Critical Web Application Security Risks.
URL: https://owasp.org/www-project-top-ten/ (дата звернення: 10.03.2026).
2 Stuttard D., Pinto M. The Web Application Hacker's Handbook: Finding and
Exploiting Security Flaws. 2nd ed. Wiley, 2011. 912 p.
3 Kali Linux Documentation. URL: https://www.kali.org/docs/ (дата
звернення: 12.03.2026).
4 Penetration Testing Execution Standard (PTES). URL: http://www.pentest-
standard.org/ (дата звернення: 12.03.2026).
5 Subfinder – Fast passive subdomain enumeration tool. URL:
https://github.com/projectdiscovery/subfinder (дата звернення: 15.03.2026).
6 Assetfinder – Find domains and subdomains related to a given domain. URL:
https://github.com/tomnomnom/assetfinder (дата звернення: 15.03.2026).
7 Certificate Transparency Logs. crt.sh. URL: https://crt.sh/ (дата звернення:
15.03.2026).
8 HTTPX – A fast and multi-purpose HTTP toolkit. URL:
https://github.com/projectdiscovery/httpx (дата звернення: 17.03.2026).
9 Nmap Network Scanning. Official Guide to the Nmap Security Scanner. URL:
https://nmap.org/book/ (дата звернення: 17.03.2026).
10 Nuclei – Fast and customizable vulnerability scanner. URL:
https://github.com/projectdiscovery/nuclei (дата звернення: 18.03.2026).
11 SQLMap – Automatic SQL injection and database takeover tool. URL:
https://sqlmap.org/ (дата звернення: 18.03.2026).
12 Exploit Database. Searchsploit Manual. URL: https://www.exploit-
db.com/searchsploit (дата звернення: 18.03.2026).
13 CVE – Common Vulnerabilities and Exposures. URL: https://cve.mitre.org/
(дата звернення: 20.03.2026).
14 Python Software Foundation. Python 3 Documentation. URL:
https://docs.python.org/3/ (дата звернення: 20.03.2026).
97
ЧДТУ 262265.026 ПЗ
15 Riverbank Computing. PyQt6 Reference Guide. URL:
https://www.riverbankcomputing.com/static/Docs/PyQt6/ (дата звернення:
22.03.2026).
16 SQLite Documentation. URL: https://www.sqlite.org/docs.html (дата
звернення: 22.03.2026).
17 Lutz M. Learning Python. 5th ed. O'Reilly Media, 2013. 1594 p.
18 Summerfield M. Python in Practice. Addison-Wesley Professional, 2013. 245
p.
19 Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1994. 395 p.
20 Fowler M. Patterns of Enterprise Application Architecture. Addison-Wesley,
2002. 533 p.
21 UML 2.5 Specification. Object Management Group. URL:
https://www.omg.org/spec/UML/2.5/ (дата звернення: 25.03.2026).
22 Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User
Guide. 2nd ed. Addison-Wesley, 2005. 496 p.
23 Pressman R. Software Engineering: A Practitioner's Approach. 8th ed.
McGraw-Hill, 2014. 976 p.
24 Sommerville I. Software Engineering. 10th ed. Pearson, 2015. 816 p.
25 Beck K. Test Driven Development: By Example. Addison-Wesley, 2002. 240
p.
26 pytest Documentation. URL: https://docs.pytest.org/en/stable/ (дата
звернення: 28.03.2026).
27 Python subprocess module documentation. URL:
https://docs.python.org/3/library/subprocess.html (дата звернення:
28.03.2026).
28 Python sqlite3 module documentation. URL:
https://docs.python.org/3/library/sqlite3.html (дата звернення: 28.03.2026).
29 Qt Documentation. Signals and Slots. URL: https://doc.qt.io/qt-
6/signalsandslots.html (дата звернення: 30.03.2026).
98
ЧДТУ 262265.026 ПЗ
30 Qt Documentation. QThread Class. URL: https://doc.qt.io/qt-6/qthread.html
(дата звернення: 30.03.2026).
31 Cloudflare IP Ranges. URL: https://www.cloudflare.com/ips/ (дата
звернення: 01.04.2026).
32 NIST National Vulnerability Database. URL: https://nvd.nist.gov/ (дата
звернення: 01.04.2026).
33 Common Weakness Enumeration (CWE). URL: https://cwe.mitre.org/ (дата
звернення: 02.04.2026).
34 OWASP Testing Guide v4.2. URL: https://owasp.org/www-project-web-
security-testing-guide/ (дата звернення: 02.04.2026).
35 Kennedy D., O'Gorman J., Kearns D., Aharoni M. Metasploit: The Penetration
Tester's Guide. No Starch Press, 2011. 328 p.
36 Weidman G. Penetration Testing: A Hands-On Introduction to Hacking. No
Starch Press, 2014. 528 p.
37 draw.io (diagrams.net) Documentation. URL: https://www.diagrams.net/
(дата звернення: 05.04.2026).
38 PlantUML Documentation. URL: https://plantuml.com/en/ (дата звернення:
05.04.2026).
39 Martin R. Clean Architecture: A Craftsman's Guide to Software Structure and
Design. Prentice Hall, 2017. 432 p.
40 Agile Manifesto. URL: https://agilemanifesto.org/ (дата звернення:
07.04.2026).
41 HTML Living Standard. URL: https://html.spec.whatwg.org/ (дата
звернення: 07.04.2026).
42 JSON Data Interchange Syntax. ECMA-404. URL: https://www.json.org/
(дата звернення: 08.04.2026).
43 CSV Format RFC 4180. URL: https://datatracker.ietf.org/doc/html/rfc4180
(дата звернення: 08.04.2026).
44 DNS – Domain Name System. RFC 1034. URL:
https://datatracker.ietf.org/doc/html/rfc1034 (дата звернення: 10.04.2026).
99
ЧДТУ 262265.026 ПЗ
45 HTTP/1.1 Specification. RFC 7230. URL:
https://datatracker.ietf.org/doc/html/rfc7230 (дата звернення: 10.04.2026).
100
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
“____” ______________ 2026 р.
«Програмний комплекс тестування web-ресурсів на вразливість»
Специфікація
482.ЧДТУ 262265.026
Листів 2
Розробник ________________ Уваєв Б. С.
Керівник ________________ Немченко О. І.
2026
482.ЧДТУ 262265.026 2
Позначення Найменування Примітка
Документація
482.ЧДТУ 262265 12 01 Текст програми
482.ЧДТУ 262265 34 01 Інструкція користувачеві
482.ЧДТУ 262265 90 01 Графічні матеріали
102
ДОДАТОК Б
«Програмний комплекс тестування web-ресурсів на вразливість»
Текст програми
482.ЧДТУ 262265 12 01
Листів 21
Розробник ________________ Уваєв Б. С.
2026
482.ЧДТУ 262265 12 01 2
MAIN_WINDOW
class ScanThread(QThread):
log_signal = pyqtSignal(str)
finished_signal = pyqtSignal(bool, dict)
def __init__(self, domain: str, scan_options: dict):
super().__init__()
self.domain = domain
self.scan_options = scan_options
self.task_manager = None
def run(self):
self.task_manager = TaskManager()
success = self.task_manager.start_scan(self.domain, self.scan_options)
status = self.task_manager.get_status()
self.finished_signal.emit(success, status)
def stop(self):
if self.task_manager:
self.task_manager.stop_current_task()
class MainWindow(QMainWindow):
def __init__(self):
super().__init__()
self.scan_thread = None
self.current_session_id = None
self.init_ui()
def init_ui(self):
self.setWindowTitle("PentestTool - Automated Reconnaissance System")
self.setGeometry(100, 100, 1200, 800)
central_widget = QWidget()
self.setCentralWidget(central_widget)
main_layout = QVBoxLayout()
central_widget.setLayout(main_layout)
main_layout.addWidget(self._create_target_section())
self.tabs = QTabWidget()
main_layout.addWidget(self.tabs)
self.log_text = QTextEdit()
self.tabs.addTab(self.log_text, "Логи")
self.subdomains_table = self._create_table(["Субдомен", "Джерело"])
self.tabs.addTab(self.subdomains_table, "Субдомени")
self.ports_table = self._create_table(["IP", "Порт", "Протокол",
"Сервіс", "Версія"])
self.tabs.addTab(self.ports_table, "Порти")
self.vulns_table = self._create_table(["Інструмент", "Критичність",
"Ціль", "Опис", "CVE ID"])
self.tabs.addTab(self.vulns_table, "Вразливості")
def _create_target_section(self) -> QGroupBox:
group = QGroupBox("Ціль сканування")
layout = QVBoxLayout()
input_layout = QHBoxLayout()
self.domain_input = QLineEdit()
self.domain_input.setPlaceholderText("example.com")
input_layout.addWidget(self.domain_input)
layout.addLayout(input_layout)
buttons_layout = QHBoxLayout()
self.start_button = QPushButton("Запустити сканування")
self.start_button.clicked.connect(self.start_scan)
buttons_layout.addWidget(self.start_button)
104
482.ЧДТУ 262265 12 01 3
self.stop_button = QPushButton("Зупинити")
self.stop_button.clicked.connect(self.stop_scan)
buttons_layout.addWidget(self.stop_button)
self.export_button = QPushButton("Експортувати результати")
self.export_button.clicked.connect(self.export_results)
buttons_layout.addWidget(self.export_button)
layout.addLayout(buttons_layout)
group.setLayout(layout)
return group
def start_scan(self):
domain = self.domain_input.text().strip()
if not domain:
QMessageBox.warning(self, "Помилка", "Введіть домен для сканування")
return
scan_options = {
'run_httpx': True, 'run_nmap': True,
'run_nuclei': True, 'run_sqlmap': True
}
self.scan_thread = ScanThread(domain, scan_options)
self.scan_thread.log_signal.connect(self.append_log)
self.scan_thread.finished_signal.connect(self.scan_finished)
self.scan_thread.start()
def stop_scan(self):
if self.scan_thread and self.scan_thread.isRunning():
self.scan_thread.stop()
def scan_finished(self, success: bool, status: dict):
if success:
self.current_session_id = status.get('session_id')
self._load_results_to_tables()
self.export_button.setEnabled(True)
def export_results(self):
export_module = ExportModule()
export_module.export_session(self.current_session_id, ['json', 'csv'])
export_module.export_full_html_report(self.current_session_id)
export_module.close()
def append_log(self, message: str):
self.log_text.append(message)
DATABASE
class Database:
def __init__(self, db_path: str = "data/pentesttool.db"):
self.db_path = db_path
Path(db_path).parent.mkdir(parents=True, exist_ok=True)
self.connection = None
self._init_database()
def _init_database(self):
self.connection = sqlite3.connect(self.db_path)
self.connection.row_factory = sqlite3.Row
self._create_tables()
self._migrate_database()
def _create_tables(self):
cursor = self.connection.cursor()
cursor.execute("""
CREATE TABLE IF NOT EXISTS targets (
105
482.ЧДТУ 262265 12 01 4
id INTEGER PRIMARY KEY AUTOINCREMENT,
domain TEXT UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)""")
cursor.execute("""
CREATE TABLE IF NOT EXISTS scan_sessions (
id INTEGER PRIMARY KEY AUTOINCREMENT,
target_id INTEGER NOT NULL,
session_name TEXT,
status TEXT DEFAULT 'running',
started_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
completed_at TIMESTAMP,
FOREIGN KEY (target_id) REFERENCES targets(id) ON DELETE CASCADE
)""")
cursor.execute("""
CREATE TABLE IF NOT EXISTS subdomains (
id INTEGER PRIMARY KEY AUTOINCREMENT,
target_id INTEGER NOT NULL,
session_id INTEGER NOT NULL,
subdomain TEXT NOT NULL,
source TEXT,
UNIQUE(session_id, subdomain),
FOREIGN KEY (session_id) REFERENCES scan_sessions(id) ON DELETE
CASCADE
)""")
cursor.execute("""
CREATE TABLE IF NOT EXISTS ips (
id INTEGER PRIMARY KEY AUTOINCREMENT,
ip_address TEXT UNIQUE NOT NULL,
is_cloudflare BOOLEAN DEFAULT 0
)""")
cursor.execute("""
CREATE TABLE IF NOT EXISTS ports (
id INTEGER PRIMARY KEY AUTOINCREMENT,
ip_id INTEGER NOT NULL,
session_id INTEGER NOT NULL,
port INTEGER NOT NULL,
protocol TEXT DEFAULT 'tcp',
service TEXT,
version TEXT,
FOREIGN KEY (ip_id) REFERENCES ips(id) ON DELETE CASCADE
)""")
cursor.execute("""
CREATE TABLE IF NOT EXISTS vulnerabilities (
id INTEGER PRIMARY KEY AUTOINCREMENT,
session_id INTEGER NOT NULL,
tool_name TEXT,
severity TEXT,
cve_id TEXT,
description TEXT,
target TEXT,
fix_info TEXT,
FOREIGN KEY (session_id) REFERENCES scan_sessions(id) ON DELETE
CASCADE
)""")
self.connection.commit()
def create_target(self, domain: str) -> Optional[int]:
cursor = self.connection.cursor()
cursor.execute("INSERT OR IGNORE INTO targets (domain) VALUES (?)",
(domain,))
self.connection.commit()
cursor.execute("SELECT id FROM targets WHERE domain = ?", (domain,))
result = cursor.fetchone()
106
482.ЧДТУ 262265 12 01 5
return result[0] if result else None
def create_scan_session(self, target_id: int, session_name: str = None) ->
Optional[int]:
cursor = self.connection.cursor()
cursor.execute(
"INSERT INTO scan_sessions (target_id, session_name) VALUES (?, ?)",
(target_id, session_name)
)
self.connection.commit()
return cursor.lastrowid
def update_session_status(self, session_id: int, status: str):
cursor = self.connection.cursor()
completed_at = datetime.now() if status in ['completed', 'failed'] else
None
cursor.execute(
"UPDATE scan_sessions SET status = ?, completed_at = ? WHERE id =
?",
(status, completed_at, session_id)
)
self.connection.commit()
def get_connection(self) -> sqlite3.Connection:
return self.connection
def close(self):
if self.connection:
self.connection.close()
self.connection = None
SUBDOMAIN_ENUM
class SubdomainEnumerationModule(BaseModule):
def __init__(self, config: Optional[dict] = None):
super().__init__(config)
self.tools = self.config.get('tools', ['subfinder', 'assetfinder'])
self.timeout = self.config.get('timeout', 300)
self.subdomains: Set[str] = set()
self.current_process = None
def validate(self, domain: str) -> bool:
domain_pattern = re.compile(
r'^(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-
Z]{2,}$'
)
return bool(domain_pattern.match(domain))
def run(self, domain: str, target_id: int, session_id: int) -> List[str]:
if not self.validate(domain):
return []
self._should_stop = False
self.subdomains.clear()
for tool in self.tools:
if self._should_stop:
break
if tool == 'subfinder':
self._run_subfinder(domain)
elif tool == 'assetfinder':
self._run_assetfinder(domain)
if not self._should_stop:
self._run_crtsh(domain)
self.results = list(self.subdomains)
107
482.ЧДТУ 262265 12 01 6
self.logger.info(f"Знайдено {len(self.results)} унікальних субдоменів")
return self.results
def _run_subfinder(self, domain: str):
self.current_process = subprocess.Popen(
['subfinder', '-d', domain, '-silent'],
stdout=subprocess.PIPE, stderr=subprocess.PIPE,
text=True, preexec_fn=os.setsid
)
start_time = time.time()
while self.current_process.poll() is None:
if self._should_stop:
self.current_process.kill()
return
if time.time() - start_time > self.timeout:
self.current_process.terminate()
return
time.sleep(0.1)
stdout, _ = self.current_process.communicate()
for subdomain in stdout.strip().split('\n'):
subdomain = subdomain.strip()
if subdomain and self._is_valid_subdomain(subdomain):
self.subdomains.add(subdomain.lower())
def _run_assetfinder(self, domain: str):
self.current_process = subprocess.Popen(
['assetfinder', '--subs-only', domain],
stdout=subprocess.PIPE, stderr=subprocess.PIPE,
text=True, preexec_fn=os.setsid
)
start_time = time.time()
while self.current_process.poll() is None:
if self._should_stop:
self.current_process.terminate()
return
if time.time() - start_time > self.timeout:
self.current_process.terminate()
return
time.sleep(0.1)
stdout, _ = self.current_process.communicate()
for subdomain in stdout.strip().split('\n'):
subdomain = subdomain.strip()
if subdomain and self._is_valid_subdomain(subdomain):
self.subdomains.add(subdomain.lower())
def _run_crtsh(self, domain: str):
url = f"https://crt.sh/?q=%.{domain}&output=json"
response = requests.get(url, timeout=30)
for entry in response.json():
for name in entry.get('name_value', '').split('\n'):
name = name.strip().lower()
if name.startswith('*.'):
name = name[2:]
if name and self._is_valid_subdomain(name) and domain in name:
self.subdomains.add(name)
def _is_valid_subdomain(self, subdomain: str) -> bool:
pattern = re.compile(
r'^(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)*'
r'[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?$'
)
return bool(pattern.match(subdomain))
def save_results(self, db_connection) -> bool:
108
482.ЧДТУ 262265 12 01 7
if not self.results or not self.target_id or not self.session_id:
return False
cursor = db_connection.cursor()
for subdomain in self.results:
cursor.execute(
"""INSERT OR REPLACE INTO subdomains
(target_id, session_id, subdomain, source)
VALUES (?, ?, ?, ?)""",
(self.target_id, self.session_id, subdomain, 'subdomain_enum')
)
db_connection.commit()
return True
def stop(self):
self._should_stop = True
if self.current_process:
os.killpg(os.getpgid(self.current_process.pid), signal.SIGTERM)
super().stop()
DNS
class DNSResolverModule(BaseModule):
def __init__(self, config: Optional[dict] = None):
super().__init__(config)
self.threads = self.config.get('threads', 30)
self.timeout = self.config.get('timeout', 5)
self.retry_count = self.config.get('retry_count', 3)
self.cloudflare_ranges: Set[ipaddress.IPv4Network] = set()
self.resolved_data: List[Dict] = []
self._wildcard_ips: Set[str] = set()
self._load_cloudflare_ranges()
def _load_cloudflare_ranges(self):
response = requests.get('https://www.cloudflare.com/ips-v4', timeout=10)
for range_str in response.text.strip().split('\n'):
try:
self.cloudflare_ranges.add(ipaddress.IPv4Network(range_str.strip()))
except ValueError:
pass
def _is_cloudflare_ip(self, ip: str) -> bool:
try:
ip_obj = ipaddress.IPv4Address(ip)
return any(ip_obj in network for network in self.cloudflare_ranges)
except ValueError:
return False
def _detect_wildcard(self, domain: str) -> Set[str]:
wildcard_ips: Set[str] = set()
try:
random_sub = ''.join(random.choices(string.ascii_lowercase, k=16)) +
'.' + domain
ips = socket.getaddrinfo(random_sub, None, socket.AF_INET)
for ip_info in ips:
wildcard_ips.add(ip_info[4][0])
except socket.gaierror:
pass
return wildcard_ips
def run(self, subdomains: List[str], session_id: int) -> List[Dict]:
if not subdomains:
return []
109
482.ЧДТУ 262265 12 01 8
self._should_stop = False
self.session_id = session_id
self.resolved_data.clear()
parts = subdomains[0].split('.')
base_domain = '.'.join(parts[-2:]) if len(parts) >= 2 else subdomains[0]
self._wildcard_ips = self._detect_wildcard(base_domain)
with ThreadPoolExecutor(max_workers=self.threads) as executor:
futures = [executor.submit(self._resolve_subdomain, sub) for sub in
subdomains]
while futures:
if self._should_stop:
for f in futures:
f.cancel()
executor.shutdown(wait=False)
break
done, futures = wait(futures, timeout=0.5,
return_when=FIRST_COMPLETED)
for future in done:
result = future.result()
if result:
self.resolved_data.append(result)
self.results = self.resolved_data
return self.results
def _resolve_subdomain(self, subdomain: str) -> Optional[Dict]:
if self._should_stop:
return None
for attempt in range(self.retry_count):
try:
ips = socket.getaddrinfo(subdomain, None, socket.AF_INET)
unique_ips = {ip_info[4][0] for ip_info in ips}
if unique_ips:
ip_data = [{
'ip': ip,
'is_cloudflare': self._is_cloudflare_ip(ip),
'is_wildcard': ip in self._wildcard_ips
} for ip in unique_ips]
return {
'subdomain': subdomain,
'ips': ip_data,
'resolved': True,
'is_wildcard': any(d['is_wildcard'] for d in ip_data)
}
except (socket.gaierror, socket.timeout):
if attempt < self.retry_count - 1:
time.sleep(0.5)
return None
return None
def save_results(self, db_connection) -> bool:
if not self.results or not self.session_id:
return False
cursor = db_connection.cursor()
for record in self.results:
cursor.execute(
"SELECT id FROM subdomains WHERE subdomain = ?",
(record['subdomain'],)
)
subdomain_row = cursor.fetchone()
if not subdomain_row:
continue
110
482.ЧДТУ 262265 12 01 9
subdomain_id = subdomain_row[0]
for ip_info in record['ips']:
ip = ip_info['ip']
cursor.execute(
"INSERT OR IGNORE INTO ips (ip_address, is_cloudflare)
VALUES (?, ?)",
(ip, ip_info['is_cloudflare'])
)
cursor.execute("SELECT id FROM ips WHERE ip_address = ?", (ip,))
ip_id = cursor.fetchone()[0]
cursor.execute(
"""INSERT OR IGNORE INTO subdomain_ip_map
(subdomain_id, ip_id, session_id) VALUES (?, ?, ?)""",
(subdomain_id, ip_id, self.session_id)
)
db_connection.commit()
return True
def get_unique_ips(self, exclude_cloudflare: bool = False) -> List[str]:
unique_ips = set()
for record in self.results:
for ip_info in record['ips']:
if exclude_cloudflare and ip_info['is_cloudflare']:
continue
unique_ips.add(ip_info['ip'])
return list(unique_ips)
HTTPX
class HTTPXModule(BaseModule):
def __init__(self, config: Optional[dict] = None):
super().__init__(config)
self.threads = self.config.get('threads', 20)
self.timeout = self.config.get('timeout', 10)
self.follow_redirects = self.config.get('follow_redirects', True)
self.web_data: List[Dict] = []
self.current_process: Optional[subprocess.Popen] = None
self._proc_lock = threading.Lock()
def run(self, subdomains: List[str], session_id: int) -> List[Dict]:
if not subdomains:
return []
self._should_stop = False
self.session_id = session_id
self.web_data.clear()
self.results = self._run_httpx_bulk(subdomains)
return self.results
def _run_httpx_bulk(self, subdomains: List[str]) -> List[Dict]:
temp_file = self._write_temp_file(subdomains)
if not temp_file:
return []
try:
cmd = self._build_command(temp_file)
with self._proc_lock:
self.current_process = subprocess.Popen(
cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
text=True, preexec_fn=os.setsid
)
timer = threading.Timer(self.timeout * 2 + 30, self._on_timeout)
timer.start()
results = []
try:
111
482.ЧДТУ 262265 12 01 10
for line in self.current_process.stdout:
if self._should_stop:
break
parsed = self._safe_parse_line(line.strip())
if parsed:
results.append(parsed)
finally:
timer.cancel()
return results
except Exception as e:
self.logger.error(f"Помилка HTTPX: {e}")
return []
finally:
self._cleanup_temp(temp_file)
def _build_command(self, input_file: str) -> List[str]:
cmd = [
'httpx', '-l', input_file, '-json', '-silent',
'-timeout', str(self.timeout), '-threads', str(self.threads),
'-status-code', '-title', '-tech-detect', '-web-server'
]
if self.follow_redirects:
cmd.append('-follow-redirects')
return cmd
def _safe_parse_line(self, line: str) -> Optional[Dict]:
try:
return self._parse_httpx_result(json.loads(line))
except json.JSONDecodeError:
return None
def _parse_httpx_result(self, data: Dict) -> Optional[Dict]:
technologies = data.get('tech', [])
if isinstance(technologies, str):
technologies = [t.strip() for t in technologies.split(',')]
return {
'url': data.get('url', ''),
'host': data.get('host', ''),
'status_code': data.get('status_code', 0),
'title': (data.get('title') or '')[:512],
'web_server': data.get('webserver', ''),
'technologies': technologies,
'headers': data.get('header', {}),
}
def save_results(self, db_connection) -> bool:
if not self.results or not self.session_id:
return False
cursor = db_connection.cursor()
for record in self.results:
cursor.execute(
"SELECT id FROM subdomains WHERE subdomain = ?",
(record.get('host', ''),)
)
row = cursor.fetchone()
if not row:
continue
cursor.execute(
"""INSERT INTO technologies
(subdomain_id, session_id, technology_name, http_status, title,
headers)
VALUES (?, ?, ?, ?, ?, ?)""",
(
row[0], self.session_id,
112
482.ЧДТУ 262265 12 01 11
', '.join(record.get('technologies', [])),
record.get('status_code'),
record.get('title'),
json.dumps(record.get('headers', {}))
)
)
db_connection.commit()
return True
def _write_temp_file(self, subdomains: List[str]) -> Optional[str]:
with tempfile.NamedTemporaryFile(mode='w', delete=False, suffix='.txt')
as f:
f.write('\n'.join(subdomains))
return f.name
def _cleanup_temp(self, path: Optional[str]) -> None:
if path:
try:
os.unlink(path)
except OSError:
pass
def _kill_process(self) -> None:
with self._proc_lock:
proc = self.current_process
if proc and proc.poll() is None:
os.killpg(os.getpgid(proc.pid), signal.SIGTERM)
def _on_timeout(self) -> None:
self._should_stop = True
self._kill_process()
def stop(self):
self._should_stop = True
self._kill_process()
super().stop()
NMAP
class NmapModule(BaseModule):
def __init__(self, config: Optional[dict] = None):
super().__init__(config)
self.default_args = self.config.get('default_args', '-sV -Pn --open')
self.timeout = self.config.get('timeout', 600)
self.batch_mode = self.config.get('batch_mode', True)
self.scan_data: List[Dict] = []
self.process = None
def run(self, ips: List[str], session_id: int,
custom_args: Optional[str] = None) -> List[Dict]:
if not ips:
return []
self._should_stop = False
self.session_id = session_id
self.scan_data.clear()
results = (self._run_nmap_batch(ips, custom_args) if self.batch_mode
else self._run_nmap_sequential(ips, custom_args))
self.results = results
return self.results
def _run_nmap_batch(self, ips: List[str],
custom_args: Optional[str] = None) -> List[Dict]:
113
482.ЧДТУ 262265 12 01 12
with tempfile.NamedTemporaryFile(mode='w', delete=False, suffix='.txt')
as f:
f.write('\n'.join(ips))
ip_file = f.name
with tempfile.NamedTemporaryFile(mode='w', delete=False, suffix='.xml')
as f:
output_file = f.name
try:
args_str = custom_args or self.default_args
cmd = ['nmap', '-iL', ip_file, '-oX', output_file] +
args_str.split()
self.process = subprocess.Popen(
cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
text=True, preexec_fn=os.setsid
)
start_time = time.time()
while self.process.poll() is None:
if self._should_stop:
os.killpg(os.getpgid(self.process.pid), signal.SIGTERM)
return []
if time.time() - start_time > self.timeout:
os.killpg(os.getpgid(self.process.pid), signal.SIGTERM)
break
time.sleep(0.5)
self.process.communicate()
if os.path.exists(output_file) and os.path.getsize(output_file) > 0:
return self._parse_nmap_xml(output_file)
return []
finally:
for f in [ip_file, output_file]:
try: os.unlink(f)
except: pass
def _run_nmap_sequential(self, ips: List[str],
custom_args: Optional[str] = None) -> List[Dict]:
results = []
for ip in ips:
if self._should_stop:
break
with tempfile.NamedTemporaryFile(mode='w', delete=False,
suffix='.xml') as f:
output_file = f.name
try:
args_str = custom_args or self.default_args
cmd = ['nmap', ip, '-oX', output_file] + args_str.split()
self.process = subprocess.Popen(
cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
text=True, preexec_fn=os.setsid
)
start_time = time.time()
while self.process.poll() is None:
if self._should_stop:
os.killpg(os.getpgid(self.process.pid), signal.SIGTERM)
return results
if time.time() - start_time > self.timeout:
os.killpg(os.getpgid(self.process.pid), signal.SIGTERM)
break
time.sleep(0.5)
self.process.communicate()
if os.path.exists(output_file):
results.extend(self._parse_nmap_xml(output_file))
finally:
try: os.unlink(output_file)
except: pass
114
482.ЧДТУ 262265 12 01 13
self.process = None
return results
def _parse_nmap_xml(self, xml_file: str) -> List[Dict]:
results = []
tree = ET.parse(xml_file)
for host in tree.getroot().findall('host'):
address = host.find('address')
if address is None:
continue
ip = address.get('addr')
ports = host.find('ports')
if ports is None:
continue
for port in ports.findall('port'):
state = port.find('state')
if state is None or state.get('state') != 'open':
continue
service = port.find('service')
product = service.get('product', '') if service is not None else
''
version = service.get('version', '') if service is not None else
''
results.append({
'ip': ip,
'port': int(port.get('portid')),
'protocol': port.get('protocol', 'tcp'),
'state': 'open',
'service': service.get('name', '') if service is not None
else '',
'version': f"{product} {version}".strip()
})
return results
def save_results(self, db_connection) -> bool:
if not self.results or not self.session_id:
return False
cursor = db_connection.cursor()
for record in self.results:
cursor.execute("SELECT id FROM ips WHERE ip_address = ?",
(record['ip'],))
row = cursor.fetchone()
if not row:
continue
cursor.execute(
"""INSERT INTO ports
(ip_id, session_id, port, protocol, state, service, version)
VALUES (?, ?, ?, ?, ?, ?, ?)""",
(row[0], self.session_id, record['port'], record['protocol'],
record['state'], record['service'], record['version'])
)
db_connection.commit()
return True
def stop(self):
self._should_stop = True
if self.process and self.process.poll() is None:
try:
os.killpg(os.getpgid(self.process.pid), signal.SIGTERM)
self.process.wait(timeout=2)
except subprocess.TimeoutExpired:
os.killpg(os.getpgid(self.process.pid), signal.SIGKILL)
except Exception:
self.process.kill()
super().stop()
115
482.ЧДТУ 262265 12 01 14
VULNERABILITY_SCANNER
class VulnerabilityScannerModule(BaseModule):
def __init__(self, config: Optional[dict] = None):
super().__init__(config)
self.run_nuclei = self.config.get('run_nuclei', True)
self.run_sqlmap = self.config.get('run_sqlmap', True)
self.run_searchsploit = self.config.get('run_searchsploit', True)
self.run_nmap_vuln = self.config.get('run_nmap_vuln', True)
self.timeout = self.config.get('timeout', 600)
self.vulnerabilities: List[Dict] = []
self.current_process = None
def run(self, session_id: int, db_connection) -> List[Dict]:
if not session_id:
return []
self._should_stop = False
self.session_id = session_id
self.vulnerabilities.clear()
web_targets = self._get_web_targets(db_connection)
ports_data = self._get_ports_data(db_connection)
if self.run_nuclei and web_targets and not self._should_stop:
self.vulnerabilities.extend(self._run_nuclei(web_targets))
if self.run_sqlmap and web_targets and not self._should_stop:
self.vulnerabilities.extend(self._run_sqlmap(web_targets))
if self.run_searchsploit and ports_data and not self._should_stop:
self.vulnerabilities.extend(self._run_searchsploit(ports_data))
if self.run_nmap_vuln and ports_data and not self._should_stop:
self.vulnerabilities.extend(self._run_nmap_vuln(ports_data))
self.results = self.vulnerabilities
return self.results
def _get_web_targets(self, db_connection) -> List[Dict]:
cursor = db_connection.cursor()
cursor.execute("""
SELECT DISTINCT s.subdomain, t.http_status
FROM subdomains s
LEFT JOIN technologies t ON s.id = t.subdomain_id
WHERE s.session_id = ? AND t.http_status IS NOT NULL
""", (self.session_id,))
targets = []
for row in cursor.fetchall():
targets.append({'url': f"https://{row[0]}", 'subdomain': row[0]})
targets.append({'url': f"http://{row[0]}", 'subdomain': row[0]})
return targets
def _get_ports_data(self, db_connection) -> List[Dict]:
cursor = db_connection.cursor()
cursor.execute("""
SELECT i.ip_address, p.port, p.service, p.version, p.id
FROM ports p JOIN ips i ON p.ip_id = i.id
WHERE p.session_id = ?
""", (self.session_id,))
return [{'ip': r[0], 'port': r[1], 'service': r[2] or '',
'version': r[3] or '', 'port_id': r[4]}
for r in cursor.fetchall()]
def _run_nuclei(self, targets: List[Dict]) -> List[Dict]:
vulnerabilities = []
116
482.ЧДТУ 262265 12 01 15
with tempfile.NamedTemporaryFile(mode='w', delete=False, suffix='.txt')
as f:
f.write('\n'.join(t['url'] for t in targets))
targets_file = f.name
with tempfile.NamedTemporaryFile(mode='w', delete=False, suffix='.json')
as f:
output_file = f.name
try:
cmd = ['nuclei', '-l', targets_file, '-json', '-o', output_file,
'-silent', '-severity', 'critical,high,medium,low']
self.current_process = subprocess.Popen(
cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True
)
while self.current_process.poll() is None:
if self._should_stop:
self.current_process.kill()
break
import time; time.sleep(0.5)
if os.path.exists(output_file):
with open(output_file) as f:
for line in f:
try:
data = json.loads(line)
vulnerabilities.append({
'tool_name': 'Nuclei',
'severity': data.get('info', {}).get('severity',
'info').upper(),
'description': data.get('info', {}).get('name',
''),
'target': data.get('host', ''),
'fix_info': data.get('info',
{}).get('remediation', ''),
'cve_id': ', '.join(
data.get('info', {}).get('classification',
{}).get('cve-id', [])
) or None
})
except json.JSONDecodeError:
continue
finally:
for f in [targets_file, output_file]:
try: os.unlink(f)
except: pass
return vulnerabilities
def _run_sqlmap(self, targets: List[Dict]) -> List[Dict]:
vulnerabilities = []
urls_with_params = [t for t in targets if '?' in t['url']][:5]
for target in urls_with_params:
if self._should_stop:
break
cmd = ['sqlmap', '-u', target['url'], '--batch',
'--level=1', '--risk=1', '--threads=2', '--timeout=10']
self.current_process = subprocess.Popen(
cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True
)
while self.current_process.poll() is None:
if self._should_stop:
self.current_process.kill()
break
import time; time.sleep(0.5)
stdout, _ = self.current_process.communicate()
if 'vulnerable' in stdout.lower():
vulnerabilities.append({
117
482.ЧДТУ 262265 12 01 16
'tool_name': 'SQLMap',
'severity': 'HIGH',
'description': 'SQL Injection vulnerability detected',
'target': target['url'],
'fix_info': 'Use parameterized queries and input
validation',
'cve_id': None
})
return vulnerabilities
def _run_searchsploit(self, ports_data: List[Dict]) -> List[Dict]:
vulnerabilities = []
services = {f"{p['service']} {p['version']}".strip()
for p in ports_data if p.get('service')}
for service in services:
if self._should_stop:
break
self.current_process = subprocess.Popen(
['searchsploit', '--json', service],
stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True
)
while self.current_process.poll() is None:
if self._should_stop:
self.current_process.kill()
break
import time; time.sleep(0.1)
stdout, _ = self.current_process.communicate()
try:
for exploit in json.loads(stdout).get('RESULTS_EXPLOIT',
[])[:3]:
vulnerabilities.append({
'tool_name': 'Searchsploit',
'severity': 'MEDIUM',
'description': exploit.get('Title', ''),
'target': service,
'fix_info': 'Update to latest version',
'cve_id': None
})
except json.JSONDecodeError:
continue
return vulnerabilities
def _run_nmap_vuln(self, ports_data: List[Dict]) -> List[Dict]:
ip_ports: Dict[str, List[int]] = {}
for p in ports_data:
ip_ports.setdefault(p['ip'], []).append(p['port'])
vulnerabilities = []
with ThreadPoolExecutor(max_workers=min(10, len(ip_ports))) as executor:
futures = {executor.submit(self._scan_ip_nmap, ip, ports): ip
for ip, ports in ip_ports.items()}
for future in as_completed(futures):
if self._should_stop:
break
vulnerabilities.extend(future.result())
return vulnerabilities
def _scan_ip_nmap(self, ip: str, ports: List[int]) -> List[Dict]:
if self._should_stop:
return []
with tempfile.NamedTemporaryFile(mode='w', delete=False, suffix='.xml')
as f:
output_file = f.name
try:
cmd = ['nmap', ip, '-p', ','.join(map(str, ports)),
118
482.ЧДТУ 262265 12 01 17
'--script', 'banner,version,discovery',
'-T4', '--host-timeout', '2m', '-oX', output_file, '-Pn']
process = subprocess.Popen(
cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True
)
import time
while process.poll() is None:
if self._should_stop:
process.kill()
return []
time.sleep(0.5)
if os.path.exists(output_file):
return self._parse_nmap_xml(output_file, ip)
finally:
try: os.unlink(output_file)
except: pass
return []
def _parse_nmap_xml(self, xml_file: str, ip: str) -> List[Dict]:
import xml.etree.ElementTree as ET
vulnerabilities = []
for host in ET.parse(xml_file).getroot().findall('host'):
for port in host.findall('.//port'):
port_id = port.get('portid')
state = port.find('state')
service = port.find('service')
if state is None or state.get('state') != 'open':
continue
for script in port.findall('script'):
output = script.get('output', '')
if not output:
continue
cve_match = re.search(r'CVE-\d{4}-\d+', output)
vulnerabilities.append({
'tool_name': 'Nmap NSE',
'severity': 'HIGH' if 'VULNERABLE' in output.upper()
else 'MEDIUM',
'description': f"{script.get('id')}: {output[:200]}",
'target': f"{ip}:{port_id}",
'fix_info': 'Check vendor security advisories',
'cve_id': cve_match.group(0) if cve_match else None
})
return vulnerabilities
def save_results(self, db_connection) -> bool:
if not self.results or not self.session_id:
return False
cursor = db_connection.cursor()
for vuln in self.results:
cursor.execute(
"""INSERT INTO vulnerabilities
(session_id, tool_name, severity, description, target, fix_info,
cve_id)
VALUES (?, ?, ?, ?, ?, ?, ?)""",
(self.session_id, vuln.get('tool_name'), vuln.get('severity'),
vuln.get('description'), vuln.get('target'),
vuln.get('fix_info'), vuln.get('cve_id'))
)
db_connection.commit()
return True
def stop(self):
self._should_stop = True
if self.current_process and self.current_process.poll() is None:
119
482.ЧДТУ 262265 12 01 18
try:
self.current_process.terminate()
self.current_process.wait(timeout=5)
except subprocess.TimeoutExpired:
self.current_process.kill()
super().stop()
VULNERABILITY_ANALYSIS
class VulnerabilityAnalysisModule(BaseModule):
VULNERABILITY_SIGNATURES = {
'apache': {
'versions': {
'2.4.49': {'cve': 'CVE-2021-41773', 'severity': 'critical',
'description': 'Path Traversal'},
'2.4.50': {'cve': 'CVE-2021-42013', 'severity': 'critical',
'description': 'Path Traversal and RCE'},
},
'patterns': [
{'pattern': r'2\.4\.(49|50)', 'severity': 'critical',
'description': 'Vulnerable Apache version'}
]
},
'openssh': {
'patterns': [
{'pattern': r'[0-6]\.\d+', 'severity': 'high', 'description':
'Outdated OpenSSH version'}
]
},
'telnet': {'severity': 'high', 'description': 'Telnet service
(unencrypted)'},
'ftp': {'severity': 'low', 'description': 'FTP service
(unencrypted)'},
}
def __init__(self, config: Optional[dict] = None):
super().__init__(config)
self.severity_threshold = self.config.get('severity_threshold',
'medium')
self.vulnerabilities: List[Dict] = []
self._nvd_cache: Dict[str, List[Dict]] = {}
def run(self, session_id: int, db_connection) -> List[Dict]:
self._should_stop = False
self.session_id = session_id
self.vulnerabilities.clear()
scan_data = self._fetch_scan_data(db_connection)
self._analyze_ports_and_services(scan_data.get('ports', []))
self._analyze_web_technologies(scan_data.get('technologies', []))
self._correlate_vulnerabilities(scan_data)
self.results = self.vulnerabilities
return self.results
def _fetch_scan_data(self, db_connection) -> Dict:
cursor = db_connection.cursor()
cursor.execute("""
SELECT p.id, p.port, p.service, p.version, i.ip_address, i.id
FROM ports p JOIN ips i ON p.ip_id = i.id
WHERE p.session_id = ?
""", (self.session_id,))
ports = [{'port_id': r[0], 'port': r[1], 'service': r[2],
120
482.ЧДТУ 262265 12 01 19
'version': r[3], 'ip': r[4], 'ip_id': r[5]}
for r in cursor.fetchall()]
cursor.execute("""
SELECT t.id, t.technology_name, t.http_status, s.subdomain, s.id
FROM technologies t JOIN subdomains s ON t.subdomain_id = s.id
WHERE t.session_id = ?
""", (self.session_id,))
technologies = [{'tech_id': r[0], 'technology': r[1], 'http_status':
r[2],
'subdomain': r[3], 'subdomain_id': r[4]}
for r in cursor.fetchall()]
return {'ports': ports, 'technologies': technologies}
def _analyze_ports_and_services(self, ports: List[Dict]):
for p in ports:
if self._should_stop:
break
service = (p.get('service') or '').lower()
version = p.get('version', '')
ip_id, port_id = p.get('ip_id'), p.get('port_id')
if service == 'telnet':
self._add_vulnerability('insecure_service', 'high',
'Telnet service detected (unencrypted)', ip_id=ip_id,
port_id=port_id,
recommendation='Use SSH instead')
if service == 'ftp':
self._add_vulnerability('insecure_service', 'low',
'FTP service detected (unencrypted)', ip_id=ip_id,
port_id=port_id,
recommendation='Use SFTP or FTPS instead')
if p.get('port') in [139, 445]:
self._add_vulnerability('smb_exposed', 'medium',
'SMB service exposed', ip_id=ip_id, port_id=port_id,
recommendation='Restrict SMB to trusted networks')
if service and version:
self._check_service_version(service, version, ip_id, port_id)
def _check_service_version(self, service: str, version: str,
ip_id: int, port_id: int):
for key, data in self.VULNERABILITY_SIGNATURES.items():
if key in service:
for ver, info in data.get('versions', {}).items():
if ver in version:
self._add_vulnerability('vulnerable_version',
info['severity'],
f"{service} {version}: {info['description']}",
cve_id=info.get('cve'), ip_id=ip_id,
port_id=port_id)
for pat in data.get('patterns', []):
if re.search(pat['pattern'], version):
self._add_vulnerability('outdated_version',
pat['severity'],
f"{service} {version}: {pat['description']}",
ip_id=ip_id, port_id=port_id)
self._lookup_nvd_cves(service, version, ip_id, port_id)
def _lookup_nvd_cves(self, service: str, version: str, ip_id: int, port_id:
int):
key = f"{service}:{version}"
if key not in self._nvd_cache:
self._nvd_cache[key] = self._fetch_nvd_cves(service, version)
time.sleep(0.6)
for cve in self._nvd_cache[key]:
self._add_vulnerability('nvd_cve', cve.get('severity', 'medium'),
121
482.ЧДТУ 262265 12 01 20
f"{service} {version}: {cve.get('description', '')[:200]}",
cve_id=cve.get('cve_id'), ip_id=ip_id, port_id=port_id)
def _fetch_nvd_cves(self, product: str, version: str) -> List[Dict]:
try:
resp = requests.get(
"https://services.nvd.nist.gov/rest/json/cves/2.0",
params={'keywordSearch': f"{product} {version}",
'resultsPerPage': 5},
timeout=10
)
if resp.status_code != 200:
return []
results = []
for item in resp.json().get('vulnerabilities', []):
cve_obj = item.get('cve', {})
desc = next((d['value'] for d in cve_obj.get('descriptions', [])
if d.get('lang') == 'en'), '')
metrics = cve_obj.get('metrics', {})
cvss = metrics.get('cvssMetricV31', []) or
metrics.get('cvssMetricV30', [])
severity = cvss[0].get('cvssData', {}).get('baseSeverity',
'MEDIUM').lower() if cvss else 'medium'
if cve_obj.get('id'):
results.append({'cve_id': cve_obj['id'], 'severity':
severity, 'description': desc})
return results
except Exception:
return []
def _analyze_web_technologies(self, technologies: List[Dict]):
for t in technologies:
if self._should_stop:
break
tech = (t.get('technology') or '').lower()
sub_id = t.get('subdomain_id')
if 'php/5' in tech or 'php 5' in tech:
self._add_vulnerability('outdated_technology', 'medium',
'Outdated PHP 5.x (end of life)', subdomain_id=sub_id,
recommendation='Upgrade to PHP 8.x')
if 'jquery' in tech:
m = re.search(r'(\d+\.\d+\.\d+)', tech)
if m and int(m.group(1).split('.')[0]) < 3:
self._add_vulnerability('outdated_library', 'low',
f"Outdated jQuery {m.group(1)}", subdomain_id=sub_id,
recommendation='Update jQuery to 3.x')
def _correlate_vulnerabilities(self, scan_data: Dict):
ip_ports: Dict[str, List] = {}
for p in scan_data.get('ports', []):
ip_ports.setdefault(p['ip'], []).append(p)
for ip, port_list in ip_ports.items():
for p in [x for x in port_list if x.get('port') in [8080, 8443,
9090]]:
self._add_vulnerability('exposed_admin_panel', 'medium',
f"Admin panel potentially exposed on port {p['port']}",
ip_id=p.get('ip_id'), port_id=p.get('port_id'),
recommendation='Restrict access to admin interfaces')
def _add_vulnerability(self, vuln_type: str, severity: str, description:
str,
ip_id=None, port_id=None, subdomain_id=None,
cve_id=None, recommendation=None):
levels = {'low': 1, 'medium': 2, 'high': 3, 'critical': 4}
122
482.ЧДТУ 262265 12 01 21
if levels.get(severity, 1) < levels.get(self.severity_threshold, 2):
return
self.vulnerabilities.append({
'vuln_type': vuln_type, 'severity': severity,
'description': description, 'ip_id': ip_id,
'port_id': port_id, 'subdomain_id': subdomain_id,
'cve_id': cve_id, 'recommendation': recommendation
})
def save_results(self, db_connection) -> bool:
if not self.results or not self.session_id:
return False
cursor = db_connection.cursor()
for v in self.results:
cursor.execute(
"""INSERT INTO vulnerabilities
(session_id, ip_id, port_id, subdomain_id, vuln_type,
severity, cve_id, description, recommendation)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)""",
(self.session_id, v.get('ip_id'), v.get('port_id'),
v.get('subdomain_id'), v.get('vuln_type'), v.get('severity'),
v.get('cve_id'), v.get('description'), v.get('recommendation'))
)
db_connection.commit()
return True
123
ДОДАТОК В
«Програмний комплекс тестування web-ресурсів на вразливість»
Інструкція користувачеві
482.ЧДТУ 262265 34 01
Листів 12
Розробник________________Уваєв Б. С.
2026
482.ЧДТУ 262265 34 01 2
1. ПРИЗНАЧЕННЯ
Програмний комплекс Pentest-Tool призначений для автоматизованого
тестування web-ресурсів на вразливість. Комплекс об'єднує популярні інструменти
інформаційної безпеки в єдиний конвеєр сканування з графічним інтерфейсом
користувача, що дозволяє проводити повний цикл розвідки та пошуку
вразливостей без необхідності ручного запуску кожного інструменту окремо.
Комплекс призначений для використання фахівцями з інформаційної
безпеки, пентестерами та адміністраторами веб-систем для виявлення
вразливостей до їх експлуатації зловмисниками.
2. СИСТЕМНІ ВИМОГИ
Для коректної роботи програмного комплексу необхідно забезпечити
наступні системні вимоги:
– операційна система: Linux (Ubuntu 20.04 або новіша, Kali Linux);
– процесор: 2 ядра та вище;
– оперативна пам'ять: не менше 4 ГБ;
– вільний простір на диску: не менше 2 ГБ;
– Python 3.9 або новіший;
– встановлені зовнішні інструменти: subfinder, assetfinder, httpx, nmap, nuclei,
sqlmap, searchsploit;
– підключення до мережі Інтернет.
3. ВСТАНОВЛЕННЯ ТА ЗАПУСК
Для встановлення програмного комплексу необхідно виконати наступні
кроки. Завантажити вихідний код із репозиторію та перейти до директорії проєкту.
Встановити необхідні залежності Python за допомогою менеджера пакетів pip,
виконавши команду: pip install -r requirements.txt. Переконатись, що всі зовнішні
інструменти встановлено та доступні в системному PATH.
Для запуску програмного комплексу необхідно виконати команду python
main.py у терміналі з директорії проєкту. Після цього відкриється головне вікно
графічного інтерфейсу (рис. В.1).
125
482.ЧДТУ 262265 34 01 3
Рисунок В.1 – Головне вікно програмного комплексу Pentest-Tool
4. ПОРЯДОК РОБОТИ З ПРОГРАМНИМ КОМПЛЕКСОМ
4.1 Введення цільового домену та запуск сканування
Після запуску програми у верхній частині головного вікна розміщено поле
введення цільового домену. Користувач має ввести доменне ім'я веб-ресурсу, який
необхідно перевірити (наприклад, example.com), та натиснути кнопку «Запустити
сканування» (рис. В.2). Введення протоколу (http:// або https://) не є обов'язковим
– система визначить його автоматично.
126
482.ЧДТУ 262265 34 01 4
Рисунок В.2 – Введення адреси цільового домену
Якщо введено некоректний формат домену, система відобразить
повідомлення про помилку (рис. В.3) і сканування не буде розпочато. У такому
випадку слід перевірити правильність введеної адреси та повторити спробу.
Рисунок В.3 – Повідомлення про помилку введення
127
482.ЧДТУ 262265 34 01 5
4.2 Спостереження за процесом сканування
Після запуску сканування система послідовно виконує п'ять етапів конвеєра
аналізу. Поточний стан виконання відображається у вкладці «Журнал» у режимі
реального часу (рис. В.4). У журналі фіксуються всі події: запуск модулів, знайдені
субдомени, відкриті порти та виявлені вразливості. Графічний інтерфейс
залишається активним під час сканування, що дозволяє користувачу переглядати
проміжні результати, не очікуючи завершення всього процесу.
Рисунок В.4 – Відображення процесу сканування у журналі подій
У разі необхідності перервати сканування користувач може натиснути
кнопку «Зупинити», розташовану поряд із кнопкою запуску. Система коректно
завершить роботу поточного модуля та збереже вже отримані результати до бази
даних.
4.3 Перегляд результатів сканування
Після завершення сканування результати автоматично відображаються у
трьох вкладках інтерфейсу.
128
482.ЧДТУ 262265 34 01 6
Вкладка «Субдомени» містить перелік усіх знайдених субдоменів цільового
ресурсу з їх IP-адресами та статусом доступності (рис. В.5). Субдомени, захищені
Cloudflare, позначаються відповідним маркером.
Рисунок В.5 – Результати збору субдоменів
Вкладка «Порти» відображає результати сканування відкритих портів для
кожного знайденого хосту (рис. В.6). Для кожного порту вказується його номер,
протокол, назва та версія виявленого сервісу.
129
482.ЧДТУ 262265 34 01 7
Рисунок В.6 – Результати сканування портів
Вкладка «Вразливості» містить перелік знайдених вразливостей із
зазначенням їх ідентифікаторів CVE, рівня критичності (Critical, High, Medium,
Low) та опису (рис. В.7). Результати відсортовані за рівнем критичності від
найвищого до найнижчого.
Рисунок В.7 – Виявлені вразливості
130
482.ЧДТУ 262265 34 01 8
4.4 Експорт результатів
Після завершення сканування користувач може зберегти результати у
зручному форматі. Для цього необхідно натиснути кнопку «Експорт» у нижній
частині головного вікна (рис. В.8), після чого відкриється діалогове вікно вибору
формату звіту.
Рисунок В.8 – Вікно вибору формату звіту
Система підтримує чотири формати збереження результатів:
– HTML – структурований звіт із графіками розподілу вразливостей,
загальною оцінкою безпеки ресурсу та детальним описом загроз включно з CVE
ID. Рекомендований формат для представлення результатів замовнику;
– JSON – машинозчитуваний формат для інтеграції з іншими інструментами
аналізу;
– CSV – табличний формат для обробки в електронних таблицях;
– TXT – простий текстовий формат для швидкого перегляду.
131
482.ЧДТУ 262265 34 01 9
Після вибору формату необхідно вказати шлях для збереження файлу у вікні
провідника (рис. В.9). Система повідомить про успішне збереження звіту
відповідним повідомленням.
Рисунок В.9 – Приклад згенерованого HTML-звіту
132
482.ЧДТУ 262265 34 01 10
4.5 Робота з історією сканувань
Програмний комплекс автоматично зберігає результати кожного сканування
до вбудованої бази даних SQLite. Для перегляду попередніх сесій необхідно
відкрити панель «Історія сесій» у лівій частині головного вікна (рис. В.10). У
переліку відображаються всі попередні сканування із зазначенням дати, часу та
сканованого домену.
Рисунок В.10 – Перегляд збережених сесій сканування
Для завантаження результатів попередньої сесії необхідно натиснути на
відповідний запис у переліку. Система відразу відобразить збережені результати у
вкладках «Субдомени», «Порти» та «Вразливості» без необхідності повторного
запуску сканування.
5. ТИПОВІ ПОМИЛКИ ТА ЇХ УСУНЕННЯ
У таблиці В.1 наведено перелік типових помилок, що можуть виникнути під
час роботи з програмним комплексом, та способи їх усунення.
133
482.ЧДТУ 262265 34 01 11
Таблиця В.1
Типові помилки та способи їх усунення
Помилка Причина Спосіб усунення
Tool not found: Інструмент не встановлено Встановити subfinder та
subfinder або відсутній у PATH додати до PATH: export
PATH=$PATH:~/go/bin
Permission denied Nmap потребує root для Запустити програму через
при скануванні SYN-сканування sudo python main.py
портів
No subdomains Домен не має публічних Перевірити правильність
found субдоменів або закритий домену, спробувати інший
інструмент збору
Database is locked Декілька екземплярів Закрити всі копії програми та
програми відкриті перезапустити
одночасно
httpx: connection Хост недоступний або Перевірити підключення до
timeout заблокував запити мережі, збільшити таймаут у
налаштуваннях
nuclei: no templates Шаблони nuclei не Виконати nuclei -update-
found завантажені templates у терміналі
sqlmap: false Занадто агресивні Зменшити рівень
positive results параметри сканування агресивності (--level, --risk) у
налаштуваннях модуля
PyQt6: cannot Запуск без графічного Запускати лише з активним
connect to display середовища (наприклад, графічним сеансом або
через SSH) налаштувати X11 forwarding
Scan takes too long Велика кількість Обмежити діапазон портів
субдоменів або відкритих nmap або кількість потоків у
портів налаштуваннях
134
482.ЧДТУ 262265 34 01 12
Помилка «Tool not found» означає, що один із зовнішніх інструментів
(subfinder, nmap, nuclei тощо) не встановлено або не доступний у системному
PATH. Необхідно встановити відсутній інструмент відповідно до офіційної
документації та переконатися, що він доступний у терміналі.
Помилка «Permission denied» під час сканування портів виникає через
недостатні права для запуску nmap у режимі SYN-сканування. Слід запустити
програму з правами адміністратора (sudo python main.py) або налаштувати
відповідні дозволи для nmap.
Відсутність результатів у вкладці «Вразливості» після завершення
сканування може свідчити про те, що жодних вразливостей не виявлено, або про
те, що ресурс захищений WAF чи іншими засобами захисту. Рекомендується
перевірити журнал подій на наявність повідомлень про помилки окремих модулів.
Повільна робота або зависання інтерфейсу під час сканування великих
доменів із значною кількістю субдоменів є очікуваною поведінкою. Журнал
продовжує оновлюватись у фоновому режимі. Не рекомендується примусово
завершувати процес, оскільки це може призвести до часткового збереження
результатів.
135
ДОДАТОК Г
«Програмний комплекс тестування web-ресурсів на вразливість»
Графічні матеріали
482.ЧДТУ 262265 90 01
Листів 16
Розробник ________________ Уваєв Б. С.
2026
482.ЧДТУ 262265 90 01 2
Рисунок Г.1 – Тема роботи
Рисунок Г.2 – Вступ
137
482.ЧДТУ 262265 90 01 3
Рисунок Г.3 – Вступ
Рисунок Г.4 – Методи та засоби розвязання поставлених завдань
138
482.ЧДТУ 262265 90 01 4
Рисунок Г.5 – Актуальність задачі
Рисунок Г.6 – Аналіз існуючих програмних засобів
139
482.ЧДТУ 262265 90 01 5
Рисунок Г.7 – Аналіз способів вирішення задачі
Рисунок Г.8 – Постановка задачі
140
482.ЧДТУ 262265 90 01 6
Рисунок Г.9 – Результати робіт на етапі аналізу вимог
Рисунок Г.10 – Первинні та детальні вимоги(замовника)
141
482.ЧДТУ 262265 90 01 7
Рисунок Г.11 – Первинні та детальні вимоги(розробника)
Рисунок Г.12 – Діаграма прецедентів
142
482.ЧДТУ 262265 90 01 8
Рисунок Г.13 – Діаграма прецедентів
Рисунок Г.14 – Проектування логічної структури
143
482.ЧДТУ 262265 90 01 9
Рисунок Г.15 – Архітектурне проектування
Рисунок Г.16 – Моделювання поведінки системи
144
482.ЧДТУ 262265 90 01 10
Рисунок Г.17 – Моделювання поведінки системи
Рисунок Г.18 – Моделювання поведінки системи
145
482.ЧДТУ 262265 90 01 11
Рисунок Г.19 – Об’ґрунтування вибору засобів реалізації
Рисунок Г.20 – Структурна та функціональна схеми
146
482.ЧДТУ 262265 90 01 12
Рисунок Г.21 – Логічна схема
Рисунок Г.22 – Структура бази даних
147
482.ЧДТУ 262265 90 01 13
Рисунок Г.23 – Інтерфейс користувача
Рисунок Г.24 – Тестування
148
482.ЧДТУ 262265 90 01 14
Рисунок Г.25 – Тестування
Рисунок Г.26 – Впровадження програмного комплексу
149
482.ЧДТУ 262265 90 01 15
Рисунок Г.27 – Впровадження програмного комплексу
Рисунок Г.28 – Висновки до роботи
150
482.ЧДТУ 262265 90 01 16
Рисунок Г.29 – Подяка керівнику та комісії
Рисунок Г.30 – Фінальний слайд
151