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/6508| Title: | Механізм авторизації захищеного Web-порталу приватного підприємства |
| Authors: | Гавриш, Олександр Степанович Чорнодобравська, Вікторія Анатоліївна |
| Keywords: | web-портал;wordpress;механізм авторизації;brute-force;плагіни безпеки |
| Issue Date: | 2025 |
| Abstract: | "Метою роботи є розробка та реалізація механізму авторизації захищеного web-порталу ТОВ «VRealSoft». Об'єкт дослідження – механізм авторизації на web-порталі для програмної платформи WordPress. Методи дослідження – аналіз вразливостей платформи WordPress, моделювання в середовищі локального web-сервера OpenServer, проектування багаторівневої системи захисту, тестування механізмів автентифікації." |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6508 |
| Appears in Collections: | 125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| М_125_Чорнодобравська_Гавриш.pdf Restricted Access | 4.49 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ЕЛЕКТРОННИХ ТЕХНОЛОГІЙ, АВТОТРАНСПОРТУ ТА
МАШИНОБУДУВАННЯ
КАФЕДРА РОБОТОТЕХНІЧНИХ І ТЕЛЕКОМУНІКАЦІЙНИХ СИСТЕМ ТА
КІБЕРБЕЗПЕКИ
До захисту допущено
завідувач кафедри РТСК
д.т.н., професор __________
Володимир ПАЛАГІН
"_____" грудня 2025 року
Пояснювальна записка
до випускної роботи
освітнього ступеня «магістр»
на тему: «Механізм авторизації захищеного web-порталу приватного підприємства»
Виконала студентка 2 курсу, групи мБІ-41
Спеціальність – 125 «Кібербезпека та захист
інформації»
Освітня програма – «Безпека інформаційних і
комунікаційних систем»
ЧОРНОДОБРАВСЬКА Вікторія Анатоліївна
Керівник роботи ГАВРИШ Олександр
Рецензент БОНДАРЕНКО Максим
Черкаси 2025
Форма № Н-9.01
Черкаський державний технологічний університет
(назва вузу)
Факультет електронних технологій, автотранспорту та машинобудування
Кафедра Робототехнічних і телекомунікаційних систем та кібербезпеки
Освітній ступінь магістр
Спеціальність 125 - Кібербезпека та захист інформації
Освітня програма Безпека інформаційних і комунікаційних систем
ЗАТВЕРДЖУЮ
Завідувач кафедри РТСК
д.т.н., професор Володимир ПАЛАГІН
« » вересня 2025 р.
ЗАВДАННЯ
на дипломний проект (роботу) студентці
Чорнодобравській Вікторії Анатоліївні
(прізвище, ім'я, по батькові)
1. Тема проекту (роботи) Механізм авторизації захищеного web-порталу приватного
підприємства
керівник проекту (роботи) Гавриш Олександр Степанович, к.ф.-м.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджена наказом по університету від « 15 » вересня 2025 р. № 261/03-03
2. Строк подання студентом проекту (роботи) 1 грудня 2025 р.
3. Вихідні дані до проекту (роботи) Web-портал ТОВ «VRealSoft» на базі CMS WordPress,
web-сервер NginX, мова програмування PHP, СУБД MySQL, топологія ІКС на базі Ethernet з
маршрутизатором L3, демілітаризована зона (DMZ), міжмережевий екран, 25 користувачів
(6 стаціонарних ПК, 16 ноутбуків, 3 пристрої VR/AR), вимоги НД ТЗІ 2.5-004-99, профіль .
захищеності 3.КЦД.1
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)______
Вступ. 1. Організаційна та інформаційна структура приватного підприємства «VRealSoft».
2. Інформаційно-комунікаційна система підприємства та критичні елементи структури.
3. Розробка та налаштування механізмів авторизації захищеного web-порталу. Висновки.
Список використаної літератури.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень)
Презентація в Power Point обсягом 13 плакатів
6. Консультанти з проекту (роботи) із зазначенням розділів проекту, що їх стосуються
Підпис, дата
Розділ Прізвище, ініціали та посада завдання завдання
консультанта видав прийняв
7. Дата видачі завдання 04 вересня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
№ Назва етапів дипломного проекту Строк виконання Примітка
з/ (роботи) етапів
п проекту (роботи)
1. Аналіз технічного завдання та огляд літератури 04.09.2025
2. Дослідження організаційної та інформаційної структури 11.09.2025
ТОВ «VRealSoft»
3. Аналіз топології ІКС підприємства та виділення об'єктів 18.09.2025
захисту
4. Дослідження вразливостей платформи WordPress та 25.09.2025
статистики атак
5. Формування функціонального профілю захищеності за НД 02.10.2025
ТЗІ 2.5-004-99
6. Встановлення та налаштування OpenServer, WordPress, 09.10.2025
phpMyAdmin
7 Впровадження та налаштування плагінів 16.10.2025 –
20.11.2025
8. Оформлення пояснювальної записки 20.11.2025 –
27.11.2025
9. Оформлення плакатів 01.12.2025
Студент ЧОРНОДОБРАВСЬКА Вікторія
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) ГАВРИШ Олександр
(підпис) (прізвище та ініціали)
ЗМІСТ
Стор.
Список скорочень та умовних позначень 4
Вступ 5
1. ОРГАНІЗАЦІЙНА ТА ІНФОРМАЦІЙНА СТРУКТУРА ПРИВАТНОГО 9
ПІДПРИЄМСТВА VREALSOFT
1.1 Аналіз організаційної структури підприємства 9
1.2 Існуюча ІКС підприємства та елементи її структури 14
1.3 Модель взаємодії елементів захищеного web-порталу 18
2. ІНФОРМАЦІЙНО- КОМУНІКАЦІЙНА СИСТЕМА ПІДПРИЄМСТВА
ТА КРИТИЧНІ ЕЛЕМЕНТИ СТРУКТУРИ
23
2.1 Дослідження вразливостей платформи web-порталу 23
2.2 Формування функціонального профілю захищеності механізму
авторизації за НД ТЗІ 2.5-004 -99 27
2.3 Платформа для реалізації механізму авторизації та початкова
ініціалізація 30
2.4 Механізми фіксації інцидентів безпеки спроб НСД до web-порталу 39
3. РОЗРОБКА ТА НАЛАШТУВАННЯ МЕХАНІЗМІВ АВТОРИЗАЦІЇ
ЗАХИЩЕНОГО WEB-ПОРТАЛУ 46
3.1 Базові механізми автентифікації адміністратора на порталі 46
3.2 Проектування та налаштування складників механізму автентифікації
захищеного web-порталу 48
Висновки 71
Список використаної літератури 72
Додатки
Список скорочень та умовних позначень
АС – автоматизована система;
БД – база даних;
ІА – інтелектуальні активи;
ІБ – інформаційна безпека;
ІКС – інформаційно-комунікаційна система;
ІС – інформаційна система;
ІТС – інформаційна телекомунікаційна система;
ІТ – інформаційні технології;
КЗЗ – комплекс засобів захисту;
НД – нормативний документ;
НСД – несанкціонований доступ;
ОС – операційна система;
ПЗ – програмне забезпечення;
СКУД – система контролю управління доступом;
ТОВ – товариство з обмеженою відповідальністю;
ТЗІ – технічний захист інформації;
ВСТУП
Різноманітного типу web-портали сьогодні є основними складовими глобальної
мережі Internet. Часто вони виступають в якості основного інтерфейсу для доступу до
тих чи інших сервісів або послуг. Інколи, за допомогою сервісів, що представлені на
web-порталах здійснюються фінансові транзакції, на них вводяться персональні або
конфіденційні дані тощо. На багатьох підприємствах, у зв’язку з цифровізацією
бізнес-процесів, wed-портали перейшли до групи критично важливих елементів
інфраструктури. Через таку велику кількість важливих процесів, за даними
досліджень, понад 43% кібератак спрямовані саме на такі web-додатки та web-
портали. Середні та малі підприємства зазвичай не мають належних ресурсів задля
впровадження складних систем захисту корпоративного рівня, і саме через це часто їх
wed-портали та сайти стають вразливими й страждають від кібератак. Понад 40%
сайтів у мережі Інтернет, повноцінно функціонують завдяки найпопулярнішій системі
управління контентом (CMS) WordPress. І саме ці сайти так приваблюють
кіберзлочинців, які мають на меті провести злам сайту задля викрадення даних або ж
іншого заподіяння шкоди. Оскільки базові механізми авторизації WordPress є
повністю функціональними, хоч і доволі простими, при «вдалому» підході, вони не
можуть гарантувати належного захисту і зловмисники цим часто користуються.
Також стандартна система авторизації WordPress сама по собі має ряд вразливостей
таких як:
- brute-force – приклад грубого перебору паролів та логінів у спробах
підібрати вірний і здійснити несанкціонований вхід на портал;
- відсутність обов’язкової 2FA (двофакторної автентифікації) – методу
безпеки, при якому необхідно одразу двома способами підтвердити особу для
доступу до облікового запису;
- відсутність журналу логів – автоматизований журнал, в якому
відображаються усі події (наприклад вхід в обліковий запис, зміна даних, вихід
з облікового запису);
- обмеження можливостей контролю сесій користувачів.
Важливу роль в забезпеченні інформаційної безпеки всіх критичних даних на
таких порталах забезпечують механізми авторизації. Саме при авторизації
користувачам надаються права, які були видані при реєстрації.
Правильно розроблений та реалізований механізм авторизації підвищує
репутаційний фактор привабливості бізнесу підприємства в очах замовників або
клієнтів. Механізми авторизації за умови вибору оптимальних проектних рішень не
потребують великих витрат при впровадженні і експлуатації, та можуть бути
використані на web-порталах приватних підприємств різного масштабу та рівня та
розвитку.
Актуальність розробки та практичної реалізації механізму авторизації на
web - порталі приватного підприємства, пояснюється необхідністю зменшити
кількість спроб несанкціонованого доступу, підвищити довіру клієнтів та партнерів,
забезпечити відповідність діючим законам, вимогам та стандартам, зменшити роль
людського фактору в гарантуванні захисту цілісності, конфіденційності та
доступності інформації на порталі ТОВ «VRealSoft». Результати даної роботи можна
адаптувати для використання на інших підприємствах, що використовують WordPress
Об'єктом роботи є механізм авторизації на web-порталі для програмної
платформи WordPress. Цей механізм є комплексною системою програмно-технічних
засобів, які забезпечать контроль доступу користувачів до інформаційних ресурсів та
функціональних можливостей web-порталу. Механізм включає у себе такі
взаємопов’язані компоненти:
- підсистема ідентифікації та автентифікації користувачів;
- модуль управління правами доступу;
- журнал логування;
- інтерфейси адміністрування та моніторингу.
Також він взаємодіє з web-сервером, PHP-інтерпритатором та іншими
компонентами, які використовуються з WordPress.
Даний механіхм авторизації буде забезпечувати захист від атак на етапі
автентифікації, таких як:
- brute-force;
- credential stuffing (скомпроментовані облікові записи) – розповсюджений
вид кібератак, коли зловмисники використовують облікові дані, які викрали
раніше з інших web-платформ та web-порталів, і за допомогою них намагаються
здійснити несанкціонований вхід шляхом підбору паролів;
- SQL-ін’єкції – це метод при якому зловмисник вставляє шкідливий SQL-
код у запит з метою отримати несанкціонований доступ до бази даних,
маніпулювати даними, виконувати команди на сервері;
- XSS-атаки (міжсайтинговий скриптинг) – це атаки, при яких зловмисник
впроваджує шкідливий скрипт на wed-сторінку, який потом виконується у
браузері користувача після відвідування цієї web-сторінки;
- session hijacking (перехоплення сесії) – це тип атаки, коли зловмисник
отримує несанкціонований доступ до сесії автентифікованого користувача;
- CSRF-атаки (підробка міжсайтових запитів) – зловмисник використовує
активну сесію зареєстрованого користувача і змушує його виконувати небажані
дії.
Метою роботи є розробка та реалізація механізму авторизації захищеного web-
порталу ТОВ «VRealSoft».
Задля досягнення мети слід вирішити наступні задачі:
1. Проаналізувати структури та особливості функціонування ІКС
підприємства та виділити об’єкти захисту.
2. Сформулювати функціональний профіль захищеності системи та
виділити послуги щодо захисту інформації, що підлягають подальшому
проектуванню і реалізації.
3. Обрати основані елементи механізму авторизації та визначити методи їх
ініціалізації та налаштування.
4. Вибір засобів розробки, формування алгоритму роботи програмного
забезпечення в складі механізму авторизації захищеного web-порталу.
5. Реалізувати механізм авторизації на базі прикладного ПЗ.
Структура та обсяг роботи. Робота складається із вступу, 3 розділів та
загальних висновків, переліку використаних джерел, що містить 23 найменуваня на 3
сторінках, 43 рисунки.
Загальний обсяг роботи – 67 сторінок основного тексту.
РОЗДІЛ 1 ОРГАНІЗАЦІЙНА ТА ІНФОРМАЦІЙНА СТРУКТУРА
ПРИВАТНОГО ПІДПРИЄМСТВА VREALSOFT
Приватне підприємство, яке є суб’єктом застосування механізму авторизації має
деякі особливості діяльності та протікання бізнес-процесів. Аналіз цих процесів,
виділення об’єктів захисту в ІКС та дослідження інцидентів безпеки, які призвели до
необхідності розробки нового авторизаційного механізму, дає змогу спроектувати та
реалізувати найбільш адекватний варіант.
1.1 Аналіз організаційної структури підприємства
Приватне підприємство VRealSoft розташоване за адресою: вулиця Байди
Вишневецького, 34 ,м. Черкаси, Черкаська область, 18000.
Приміщення офісу розміщене в будівлі ПАТ «УКРТЕЛЕКОМ».
Режим роботи підприємства:
- Графік роботи офісу: 9:00-18:00 (п'ятиденний робочий тиждень);
- Особливості віддаленої роботи: гнучкий графік для розробників;
- Система обліку робочого часу та контролю доступу до приміщень;
Розподіл функціональних обов'язків:
- Матриця відповідальності для кожної посади;
- Рівні доступу до інформаційних ресурсів розподілені згідно посад
працівників;
- Присутній перелік критичних користувачів з підвищеними привілеями.
На рисунку 1.1 показано розташування на мапі міста офісу ТОВ «VRealSoft».
Рисунок 1.1 – розташування ТОВ «VRealSoft»
Основними напрямками діяльності даного підприємства є:
- розробка систем віртуальної та доповненої реальності для застосування в
ігровій та бізнес індустрії;
- створення та тестування програмного забезпечення окремих систем та
компонентів віртуальної та доповненої реальності;
- супровід та технічне обслуговування проектів за напрямом роботи
підприємства;
- модернізація та удосконалення програмного та апаратного забезпечення
тренажерів, симуляторних блоків та систем технічного та виробничого
призначення.
На момент написання даної роботи виробнича програма приватного
підприємства включає чотири об’ємні проекти з віртуальної та доповненої реальності,
зокрема:
- coloring book;
- cruk;
- helmet;
- slot vr;
Короткий опис даних проектів є таким:
- Coloring book – AR-розмальовки, які є звичайними паперовими
розимальовками, але з доповненою реальністю (AR). Принцип заключається в
спеціальній програмі, яка при скануванні вже розмальованого аркуша підбирає
використані у малюванні кольори та відображає в циї кольорах 3D зображення
з картинки. Часто ці 3D зображення роблять анімованими та використовують в
анімованих інтерактивних іграх для дітей;
- CRUK (Cancer Research UK) – підприємство бере участь у проекті IMAXT,
що використовує віртуальну реальність для проведення досліджень які
стосуються раку. Вчені збирають фрагменти інформації про клітини та
пухлини, ця інформація використовується для побудови 3D- моделей, які можна
використовувати у навчанні та дослідженнях. Занесені до бази сформовані
пухлини можуть вивчати лікарі та дослідники віддалено через мережу Інтернет
з використанням голосових чатів у реальному часі. VR-система (система
віртуальної реальності) може візуалізувати відокремлення групи клітин від
основного тіла пухлини та поширення їх на навколишні тканини.
- HELMET – шоломи з AR\VR (доповненою\віртуальною реальністю).
Наприклад мотоциклетний шолом з інтегрованою доповненою реальністю.
Такий шолом проектує дані про проїздку в реальному часі, підтримує GPS
(Global Positioning System - Глобальна система позиціонування) навігацію,
дзвінки та радари стосовно обмеження швидкості.
- SLOT VR – у vr-слотах передбачено інтерактив для гравців, вони можуть
протягнути руку, щоб повернути важіль, вставити віртуальні монети у
віртуальний автомат і активувати бонусні раунди за допомогою спеціальних
жестів.
Окрім цього, підприємство займається створенням серверної частини на
клієнтській стороні, дизайном інтерфейсу, тестуванням якості.
Повна інформація про напрямки і характер здійснення діяльності та задач
даного підприємства наведена на офіційному сайті [1].
На рисунку 1.2 зображено план третього поверху будівлі з приміщеннями , які
виділені під офіс ТОВ «VRealSoft» (позначено прямокутником на плані).
Рисунок 1.2 – План приміщень офісу ТОВ «VRealSoft»
Офіс підприємства розташований на 3 поверсі 5 поверхової будівлі і складається
з 4 приміщень:
- холу-приймальні з робочим місцем офіс-менеджера;
- кабінету директора;
- приміщення для розробників систем віртуальної реальності та
тестувальників;
- приміщення для інженера сервісного обслуговування та підтримки і
фахівця з розробки електронної частини систем;
Загальний склад підприємства налічує 25 осіб. Частина персоналу працює
віддалено, що дозволяє зменшити площу орендованих приміщень. Керівником даного
підприємства є його директор.
Всього персонал, задіяний в роботі підприємства це:
1. Директор – 1 особа.
2. Офіс-менеджер – 1 особа – відповідає за безперебійність роботи у офісі,
комфорт працівників та ефективне функціонування адміністративних процесів.
3. Front-end розобник – 6 осіб – створюють лице сайтів і додатків,
відповідають за функціональність, оформлюють усе, що бачить користувач,
тобто інтерфейс.
4. Full-stack розробник – 5 особи – універсальний спеціаліст, який володіє
однаково добре навичками з front-end та back-end.
5. Розробник систем доповненої та віртуальної реальності – 2 особи –
фахівці, які створюють програми та інтерактивні середовища для доповненої чи
віртуальної реальності.
6. Головний бухгалтер – 1 особа.
7. Інженер-розробник електронних та мехатронних систем – 1 особа –
розробляє, контролює та коригує роботу мехатронних та електронних систем.
8. Фахівцець зі штучного інтелекту – 2 особи – займаються розробкою та
впровадженням штучного інтелекту у програмні продукти, досліджують нові
можливості використання штучного інтелекту у роботі.
9. IT-рекрутер – 1 особа – відповідає за пошук, відбір кандидатів та
прийняття на роботу необхідних фахівців.
10. Тестувальник ПЗ – 2 особи – перевіряє створені програми на
наявність помилок чи збоїв, відповідність встановленими вимогам.
11. Back-end – розробник – 2 особи – займаються створенням та
обслуговуванням серверної частини сайтів і додатків.
12. Менеджер з CEO – 1 особа – відповідає за загальну стратегію
управління підприємством, приймає ключові рішення, представляє
підприємство на зовнішніх заходах.
Всі приміщення офісу обладнані пожежною та охоронною сигналізаціями.
1.2 Існуюча ІКС підприємства та елементи її структури
Топологія ІКС побудована на базі телекомунікаційної технології Ethernet.
Кожен відділ підприємства підключений до окремого комутатора. Загальну
комутацію сегментів здійснює маршрутизатор рівня L3 моделі OSI, який працює на
мережевому рівні та виконує ключові функціїї маршрутизації пакетів між різними
мережами [2].
Основні характеристики L3 маршрутизатора:
- Маршрутизація пакетів між різними IP-мережами;
- Визначення найкращого шляху для передачі даних на основі таблиць
маршрутизації;
- Логічна адресація з використанням IP-адрес (IPv4 та IPv6);
- Фрагментація та збірка пакетів при необхідності;
- Фільтрація трафіку за допомогою списків контролю доступу (ACL) –
список набору правил , які визначають, хто може може виконувати з ресурсами
певні дії у комп’ютерних системах.
Протоколи маршрутизації:
- Статична маршрутизація;
- Динамічні протоколи: RIP, OSPF, EIGRP, BGP;
- Міжмережева взаємодія між різними підмережами.
Відмінності від L2 комутатора:
- L2 комутатор працює з MAC-адресами на канальному рівні;
- L3 маршрутизатор працює з IP-адресами і може з'єднувати різні мережі;
- L3 пристрій може приймати рішення про маршрутизацію на основі
IP - адрес призначення;
Зазвичай використовується для:
- З'єднання локальних мережей з Інтернетом;
- Сегментації великих мереж на підмережі;
- Забезпечення зв'язку між філіями компанії;
- Реалізації політик безпеки на мережевому рівні;
Сучасні L3 комутатори поєднують функції комутації L2 з можливостями
маршрутизації L3 та забезпечують високу продуктивність у корпоративних
мережах. Даний маршрутизатор має демілітаризовану зону, в якій працює web-
сервер підмаршрутизації приємства та розміщується web-портал, механізм
авторизації якого розроблюється. Схема топології ІКС підприємства VRealSoft
показана на рисунку 1.3.
Рисунок 1.3 – Схема топології ІКС підприємства VRealSoft
Згідно з рисунком 1.3 до web-сервера мають доступ web- клієнти, зокрема:
- Розробники з робочих місць, віддалені працівники за допомогою
захищеного каналу зв’язку для отримання актуальної інформації стосовно
розробки ПЗ та проектів;
- різноманітні програми, які самостійно проводять моніторинг веб-серверу
для отримання оновленої інформації (наприклад, ПЗ періодично переглядає
оновлення та здійснює синхронізації системою оновлення версій git);
- мобільні телефони, що отримують доступ до ресурсу веб-сервера за
допомогою протоколу WAP;
- контролери та пристрої системи віртуальної та доповненої реальності.
Хоча web-сервер і працює в демілітаризованій зоні, але від Internet він
відділений за допомогою міжмережевого екрану.
Суб’єктами доступу до ІКС підприємства є сумарно 6 стаціонарних ПК, 16
ноутбуків та 3 пристрої доповненої та віртуальної реальності. Всі ПК в мережі умовно
розбиті на 3 сегменти. В 2 сегментах комутація забезпечується роутерами R2, R4.
Роутер R5 здійснює комутацію через Wi-Fi для ноутбуків та пристроїв доповненої та
віртуальної реальності. До даного комутатора R3 зони DMZ підключений окремий
ПК, який містить ПЗ web-сервера з web-сторінкою про підприємство, напрямки його
роботи, контактну інформацію, актуальні пропозиції, вакансії тощо та ПЗ, необхідне
для роботи з пристроями VR.
Підключення ІКС підприємства до мережі Internet здійснюється через окремий
комунікаційний сервер R3.
Таким чином, задача розробки механізму авторизації полягає у необхідності
захистити конфіденційність, цілісність та доступність інформації, що розміщена на
web-сервері підприємства, який міститься в складі серверів DMZ та розташований за
зовнішнім міжмережевим екраном WAN, комунікаційний сервер R3 та
маршрутизатором R2.
Першочерговою задачею у проектуванні СКУД є необхідність її повної
сумісності в частині комунікаційного інтерфейсу технології Ethernet. Необхідно
також чітке дотримання вимог ДСТУ та відповідність існуючим нормам і законам.
1.2.1 Технологічні особливості реалізації обслуговування web-порталу
підприємства в структурі ІКС
Web-портал підприємства являє собою хостінгову платформу, що розміщується
на локальному сервері nginx [3], до якого відкритий dns-доступ з мережі Інтернет.
У адміністратора web-порталу немає окремого наданого статичного IP через те,
що свою роботу з адміністрування змісту сайту він проводить з ноутбука через мережу
Wi-Fi, доступ до якої він має через динамічний IP, який надає йому розтер через DHCP
протокол [4]. Основну роботу по супроводу сайтів порталу здійснює офіс-менеджер.
Крім безпосередньої інформації про діяльність підприємства web-портал
містить сайти та сервіси з формами он-лайн реєстрації та видачі тестових аккаунтів та
паролів для підприємства, містить платформу для трансляції потокового відео.
1.3 Модель взаємодії елементів захищеного web-порталу
Основним ІА на підприємстві, що підлягає захисту механізмом автентифікації
захищеного порталу є інтелектуальна власність, тобто: винаходи, «ноу-хау», патенти,
програмні коди тощо. Така інформація є конфіденційною.
В Цивільному кодексі України (п.2 ст.432) передбачені способи захисту прав
інтелектуальної власності, але зловмисників це не зупиняє [5].
1.3.1 Середовище функціонування механізму автентифікації
Розробка та реалізація механізму авторизації буде здійснюватися back-end
розробником з використанням програмного забезпечення, що емулює роботу хостінг
платформи. Для цього знадобиться web-сервер. Такий сервер приймає HTTP-запит від
клієнтів, зазвичай веб-браузер, і видає відповіді за протоколом HTTP, як правило, у
вигляді HTML-сторінки із зображенням, файлом, медіа-потоком або іншими даними.
Web – сервер може обслуговувати як статичні, так і динамічні сайти.
На рисунку 1.4 показано принцип взаємодії web-клієнта (браузера) та web-
сервера, коли сайти є статичними [6].
відповідь
Веб-браузер
запит
Рисунок 1.4 - принцип взаємодії web-клієнта (браузера) та web-сервера при
статичній моделі організації сайтів
Клієнт, який зазвичай є веб-браузером, передає веб-серверу запити на
отримання ресурсів, позначених URL-адресами. Ресурси - це HTML-сторінки з
файлами, зображеннями, медіа-потоком або іншими даними, які необхідні клієнтам.
У відповідь веб-сервер передає клієнту дані, які він запитував. Такий інформаційний
обмін відбувається за протоколом HTTP.
У випадку web-порталу підприємства маємо справу з динамічними сайтами, які
функціонують на базі платформи WordPress.
Динамічний сайт у даному випадку – це сайт, який складається зі змінених web-
сторінок. Вихідний код таких web-сторінок генерується під час обробки HTML-
файлового інтерпретатора мови програмування PHP. В якості мови програмування на
серверній стороні використовується мова PHP.
Узагальнений алгоритм роботи пари «клієнт»-«сервер» виглядає наступним
чином (рис.1.5):
Коли клієнт запитує динамічну web-сторінку, то запускається ланцюг подій:
1. Web-сервер отримує запит від користувача на веб-сторінку, яка
знаходиться на веб-сайті PHP.
2. Інтерпретатор PHP виконує код, розміщений у HTML-документі,
взаємодіючи при цьому, якщо це необхідно, з файловою системою, поштовим
сервером або з базовими даними.
3. Після того, як інтерпретатор виконав всі необхідні дії, він віддає
згенерований код HTML-документа web-серверу.
4. Веб-сервер передає згенерований код HTML-документ клієнту.
Рисунок 1.5 - принцип взаємодії web-клієнта (браузера) та web-сервера при
динамічній моделі організації сайтів
До переваг динамічних сайтів можна віднести наступне:
- при збільшенні кількості веб-сторінок, підтримувати динамічний сайт
досить легко, в порівнянні зі статичним, через те, що, для внесення однотипної
зміни на всіх сторінках, відредагувати код можна в одному місці, а
застосовується зміна до всіх сторінок одразу;
- додаткові функціональні можливості в роботі у вигляді інтерактивності
сторінок, додаткових механізмів захисту тощо.
До недоліків динамічного сайту слід віднести:
- динамічні веб-сторінки більш вимогливі до ресурсів хостингу в
порівнянні зі статичними;
- Динамічний сайт важче перенести на новий хостинг, тому, що необхідно
підібрати хостинг зі схожими параметрами;
- для перегляду HTML-документу в браузері, необхідно використовувати
проміжне ПЗ.
Через деякі специфічні вимоги динамічних сайтів, що в силу необхідності
входять до складу web-порталу підприємства, слід особливу увагу надати
забезпеченню доступності роботи даного ресурсу. Це треба врахувати при розробці
механізму авторизації. В разі недостатнього захисту автентифікації можливе повне
припинення роботи сервера, або розсилання з його ресурсів небажаного контенту
(спам, віруси тощо).
Висновки до розділу 1
У першому розділі дипломної роботи було проведено комплексний аналіз
інформаційної та організаційної структури приватного підприємства VRealSoft. За
результатами проведеного аналізу, визначено що є необхідність у захисті інформації,
в тому числі конфіденційної, яка стосується деяких проектів, якими зараз займається
організація.
Топологія мережі побудована на технології Ethernet з використанням
маршрутизатора L3. Web-сервер розміщений у демілітаризованій зоні (DMZ) і
захищений міжмережевим екраном.
При дослідженні web-порталу та його функціонування стало відомо, що він
реалізований на базі динамічних сайтів, за допомогою платформи WordPress, web-
сервера NginX, мови програмування PHP. Через динамічність порталу виникає
необхідність у його захищенні.
Способом належного захисту обрано розробку нового механізму авторизації.
РОЗДІЛ 2 ІНФОРМАЦІЙНО- КОМУНІКАЦІЙНА СИСТЕМА
ПІДПРИЄМСТВА ТА КРИТИЧНІ ЕЛЕМЕНТИ СТРУКТУРИ
2.1 Дослідження вразливостей платформи web-порталу
Відповідно до існуючої статистики за 2024 рік, зловмисники атакують сайти на
платформі WordPress близько 950000 разів за хвилину.
В більшості випадків для хакерів немає значення хто є власником сайту, час
його створення та інформація, що міститься на ньому. Основною їх метою є
отримання контролю над вузлом мереж і використання його ресурсів.
На платформі WordPress працює більше 30% сайтів в Інтернеті, отже, вона є
найпопулярнішою системою управління контентом. Згідно зі звітами таких сайтів як:
- OpenPR;
- Molonc;
- UploadVR;
- Apiumhub;
- CRB;
- Sucuri та інші,
можна зробити висновок, що більше 80% атак серед усіх існуючих CMS – систем
адміністрування сайтів припадає на WordPress (рис.2.1).
Рисунок 2.1 – розповсюдженість інфікованих web-ресурсів на платформах
CMS за 2024 рік
Хоча дана платформа є достатньо безпечною, її популярність та
розповсюдженість перетворюють платформу на мішень для хакерів. Для того, щоб
атаки були успішними зловмисники часто використовують для атак автоматизовані
засоби (боти), які сканують їх на предмет вразливостей. Це підвищує шанси визначити
вразливість.
На початку 2025 року приблизно 75 млн. сайтів в мережі Інтернет
функціонувало на платформі WP, тому ймовірність знайти вразливості на них для
зловмисників доволі висока.
Як правило, великі портали є найбільш привабливими для зловмисників, однак
стверджувати на всі 100%, що сайти невідомих та комерційно непривабливих
компаній та проектів не цікавитимуть зловмисників не можна.
При розробці сайтів на даній платформі ймовірність залишити помилку для
розробника все ж існує, особливо, якщо це стосується безпеки. Часто розробник-
адміністратор обирає занадто прості паролі для входу в адміністративну панель або –
небезпечний хостинг.
Тому, далі розглянемо список основних загроз безпеці для WordPress [7]:
- міжсайтове виконання сценаріїв (XSS, Cross-site Scripting) - хакер
впроваджує програмний код на сторінку сайту, а при завантаженні сторінки
даний скрипт виконується на комп'ютері користувача.
- SQL впровадження (SQLI, SQL Injections) - SQL запити виконуються з
рядка браузера.
- Завантаження файлу - файл зі шкідливим кодом завантажується на сервер.
- Фальсифікація міжсайтового запиту (CSRF, Cross-Site Request Forgery) -
код або запит виконується з рядка браузера.
- Перебір паролів (Brute Force) - множинні спроби підібрати логін і пароль.
- DoS-атаки (Denial of Servise) - спроба перевантажити і заблокувати роботу
сайту великою кількістю трафіку від шкідливих програмних ботів.
- DDoS-атаки (Distributed Denial of Servise) - спроба заблокувати роботу
сайту з різних місць, наприклад, з заражених ПК або маршрутизаторів.
- Перенаправлення - використання певної вразливості, яка переадресовує
запит до сторінки сайту на сторонню сторінку, зазвичай з метою крадіжки
особистих даних або надсилання спаму.
- Крадіжка особистих даних (Fishing) - хакери створюють сайт або
сторінку, яка схожа на сторінку авторизації цільового web-ресурсу с з метою
отримання логіну та пароля або даних платіжних засобів користувача.
- Шкідливий код (Malware) - скрипт або програма для зараження сайту.
- Впровадження файлу (LFI, Local File Inclusion) - зловмисник може
контролювати, який файл виконується в певний момент за розкладом CMS або
якогось додатку.
- Обхід авторизації (Authentication Bypass) - дірка в безпеці, яка дозволяє
хакерам обходити форму авторизації на вхід і отримувати доступ до сайту.
- Показ шляху до сайту (FPD, Full Path Disclosure) - коли відображається
повний шлях до кореневого каталогу сайту, видимі папки, логи помилок і
попереджень.
- Нумерація користувачів (User Enumeration) - можливість дізнатися логін
користувачів сайту. До URL сайту додається запит ID користувача, який може
відобразити профіль користувача з його логіном. Використовується разом з
методом перебору та підбору паролів.
- Обхід системи безпеки (Security Bypass) - зловмисники обходять систему
безпеки і отримують доступ до незахищеної частини сайту.
- Віддалене виконання коду (RCE, Remote Code Execution) - хакер запускає
виконання коду на сайті з іншого сайту або комп'ютера.
- Віддалене впровадження файлу (RFI, Remote File Inclusion) -
використання посилання на зовнішній скрипт для завантаження шкідливого
коду з іншого комп'ютера або сайту.
- Підробка запиту на стороні сервера (SSRF, Server Side Request Forgery) -
хакер керує сервером частково або повністю для виконання віддалених запитів
на свій розсуд.
Згідно з дослідженням WP WhiteSecurity [8], 54% уразливостей виявлено в
плагінах WordPress, 31,5% вразливостей в ядрі WordPress і 14,3% вразливостей - в
темах WordPress.
Якщо згрупувати всі типи вразливостей для даної платформи за типами,
відповідно до даних Wordfence та WP WhiteSecurity, то отримаємо наступні
залежності (рис.2.2).
Рисунок 2.2 – Типи вразливостей WordPress за даними досліджень Wordfence
та WP WhiteSecurity
Що стосується недоліків механізму автентифікації чи його неоптимального
налаштування, то таких налічується офіційно менше 4% від всіх вразливостей даної
платформи, але наслідки від таких недоліків є доволі серйозними.
2.2 Формування функціонального профілю захищеності механізму
авторизації за НД ТЗІ 2.5-004 -99
При проектуванні та розробці механізму авторизації захищеного web-порталу
особливе значення має захист цілісності та конфіденційності даних, що передаються
в ІКС.
Функціональний профіль захищеності являє собою перелік мінімально
необхідних рівнів послуг, які повинен реалізовувати комплекс засобів захисту
обчислювальної автоматизованої системи, щоб задовольняти певні вимоги щодо
захищеності інформації, яка обробляється в даній АС.
Стандартні функціональні профілі будуються на підставі існуючих вимог щодо
захисту інформації від певних загроз і відомих на сьогоднішній день функціональних
послуг, що дозволяють протистояти загрозам конфіденційності та цілісності для
даного випадку і забезпечити виконання вимог, які описані в задачі.
Методологічною базою для визначення вимог щодо захисту інформації в
комп'ютерних системах від несанкціонованого доступу та оцінки захищеності
інформації в комп'ютерних системах і їх придатності для обробки критичної
інформації (інформації, що вимагає захисту) є критерії нормативного документу НД
ТЗІ 2.5-004–99 [9].
Профіль захищеності для механізму авторизації можна підібрати зі стандартнтх
функціональних профілів, що будуються на підставі існуючих вимог (НД ТЗІ 2.5-005-
99 [10] ) щодо захисту певної інформації від певних загроз і відомих на сьогоднішній
день функціональних послуг, що дозволяють протистояти даним загрозам і
забезпечувати виконання вимог, які пред’являються.
Відповідно до Додатку А «Вибір профілю захищеності залежно від призначення
автоматизованих систем» НД ТЗІ 2.5-005 - 99 «Класифікація автоматизованих систем
і стандартні функціональні профілі захищеності оброблюваної інформації від
несанкціонованого доступу» можна взяти за основу послуги, що містяться в п.7 даного
додатку.
За цим пунктом, основними загрозами для інформації оброблюваної в АС
механізму авторизації користувачів на web-порталі є загрози порушення
конфіденційності, цілісності АС і технології обробки інформації.
В зазначених АС рекомендується використовувати ОС, КЗЗ яких реалізують
стандартні функціональні профілі захищеності в КС, що входять до складу АС класу
3, з підвищеними вимогами до забезпечення цілісності і доступності оброблюваної
інформації [11].
В зв’язку з тим, що авторизація користувачів відбувається через засоби мережі
Internet, то дана АС належить до класу «3» — розподілений багатомашинний
багатокористувацький комплекс, який обробляє інформацію з різними ступенями
обмеження доступу.
В такій АС існує необхідність передачі інформації через незахищене
середовище або, в загальному випадку, наявність вузлів, що реалізують різну політику
безпеки.
Для робочої машини даного підприємства, на якій встановлено підсистеми
контролю доступу з огляду на схему ІКС, доцільним є використання стандартних
функціональних профілів захищеності в комплексних системах, що входять до складу
АС класу 3, з підвищеними вимогами до забезпечення конфіденційності, цілісності і
доступності оброблюваної інформації, зокрема профіль комплексного захисту даних
першого рівня:
3.КЦД.1 = { КД-2, КО-1, КВ-1,
ЦД-1, ЦО-1, ЦВ-1,
ДР-1, ДВ-1,
НР-2, НИ-2, НК-1, НО-2, НЦ-2, НТ-2, НВ-1 },
де:
- КД-2 – дискреційний контроль доступу (рівень 2);
- КО-1 – мандатний контроль доступу (рівень 1);
- КВ-1 – контроль доступу до ресурсів;
- ЦД-1 – захист цілісності даних;
- ЦО-1 – захист цілісності об’єктів;
- ЦВ-1 – відновлення цілісності;
- ДР-1 – забезпечення доступності;
- ДВ-1 – відновлення доступності;
- НР-2 – підвищений рівень реєстрації подій;
- НИ-2 – посилена ідентифікація та автентифікація;
- НК-1 – базовий контроль достовірності/цілісності журналів;
- НО-2 – посилена невідмовність;
- НЦ-2 – підвищена цілісність протоколів реєстрації;
- НТ-2 – підвищений рівень самоконтролю/тестування;
- НВ-1 – базове відновлення після порушень.
2.3 Платформа для реалізації механізму авторизації та початкова
ініціалізація
2.3.1 Програмна реалізація середовища розробки механізму автентифкації
Для розробки та тестування механізму авторизації в режимі конструювання і
web-дизайну використовуємо CMS на базі WordPress. Дана CMS буде виконуватися
web-сервером OpenServer [12].
OpenServer – це локальний сервер, який добре працює на операційній системі
Windows. Його використовують у створенні web-сайтів і вважають одним з кращих,
оскільки він є зручним і виконує всі необхідні функції. Його доволі легко
встановлювати, після установки є все необхідне у складі програмного продукту :
- веб-сервер – NginX або Apache,
- мова програмування – PHP, з можливістю вибору версії,
- система управління базами даних – на вибір є MySQL, MariaDB,
PostgreSQL,
- вбудовані інструменти – Redis, Memcached, MongoDB.
OpenServer використовує свіжі версії програмних компонентів і регулярно
отримує оновлення, які стосуються безпеки та підтримки.
Для встановлення даного web-серверу відкриваємо конфігураційний файл
config.inc.php у папці phpmyadmin, що знаходиться в папці home у кореневому
каталозі OSPanel і редагуємо код так, як зображено на рисунку 2.3.
Рисунок 2.3 – зміна конфігураційного файлу
Після того як ми додали 32-значний ключ безпеки, змінили налаштування для
доступу, за адресою phpmyadmin (рис.2.4) стане доступним web-сервер та бази даних
порталу для користувача з правами адміністратора (рис.2.5) для подальшого
встановлення та забезпечення роботи CMS WordPress.
Рисунок 2.4 – встановлено та запущено Open Server з доступною адресою
сайту управління базами даних
Рисунок 2.5 – зарєєстрований на web-сервері користувач
Для успішної реєстраціїї на CMS WordPress заходимо на phpmyadmin і
створюємо нову базу даних з параметрами, зображеними на рисунку 2.6.
Рисунок 2.6 – створення нової бази даних для сайту
OpenServer - це безкоштовний аналог хостинга, який можна встановити на свій
персональний комп'ютер. На нього можна встановити будь-який конструктор сайтів -
WordPress, Joomla, Drupal, Ucoz.
Емуляція роботи порталу на локальному хостінгу (ПК) необхідна для того, щоб
можна було візуалізувати роботу даного ресурсу перед його розміщенням в мережі
Інтернет. Для цього використаємо CMS Wordpress. Встановлюємо та реєструємо web-
сайт, для якого буде створюватися механізм автентифікації (рис.2.7). Далі переходимо
до процедури початкового налаштування автентифікації.
Рисунок 2.7 - встановлення та перехід до реєстрації CMS Wordpress
2.3.2 Початкові параметри для авторизації та конфігурування
Початкові параметри для авторизації та конфігурування встановлюються за
замовченням та можуть бути змінені пізніше. З метою посилення захисту від сканерів
баз даних встановлюємо ім’я користувача відмінне від admin (за замовченням) та
прописуємо згенерований сильний пароль для ускладнення підбору (рис.2.8). Хост
бази даних в процесі розробки та початкового конструювання сайту встановимо таким
же, як у web-серверу: MySQL-8.4.
Рисунок 2.8 - встановлюємо початкові параметри для авторизації та
конфігурування сайту
Далі реєструємо даний сайт у розробників платформи, визначаємо назву ресурсу
в форматі dns та вводимо початкові облікові дані авторизації адміністратора після
чого авторизуємося в адмінпанелі, як адміністратор з оригінальним логіном (рис.2.9).
Рисунок 2.9 – авторизація адміністратора стандартним механізмом
Потрапляємо до панелі адміністрування сайту, з якої будуть доступні
інструменти для зміни змісту та налаштування тем, плагінів, налаштування власне
облікового запису тощо (рис.2.10).
Рисунок 2.10 – успішний вхід до панелі адміністрування сайту Wordpress
2.3.3 Модифікація ключів безпеки Wordpress
Однією зі складових безпеки WordPress – є оновлення ключів безпеки і солі
WordPress. Ключі поліпшують шифрування інформації, що зберігається
у cookies відвідувача. Також вони ускладнюють злам пароля, тому, що додають до
нього додаються випадкові елементи (сіль). Секретні фрази забезпечують ще більшу
надійність.
Платформа WordPress для автентифікації використовує cookie, які зберігаються
в браузері. Для того, щоб автентифікація була максимально безпечною ці cookie-
файли шифруються за допомогою солі і ключа безпеки.
Причини оновлення ключів безпеки і солі в WordPress є наступними:
- Початкове ініціалізаційне налаштування. Під час установки WordPress в
файлі wp-config.php будуть створені ключі безпеки і солі. Але ці ключі і солі не
будуть унікальними.
- Посилення безпеки доступу до файлу wp-config.php. Наприклад, під час
резервного копіювання файл конфігурації потрапив до зловмисника. Тоді, він
автоматично має ключі автентифікації до БД сайту.
Застосування ключів безпеки особливо слушно в тих випадках, коли необхідно
протидіяти скануванню баз даних.
У файлі конфігурації WordPress, який називається wp-config.php знаходяться
ключі безпеки. У файлі містяться константи, які належать до ключів безпеки і солі
WordPress: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, AUTH_SALT
тощо. Дані константи використовуються всередині WordPress для підвищення рівня
безпеки.
Якщо секретні ключі до файлу wp-config.php ще не були додані, це буде
виглядати так, як показано на рисунку 2.11.
Рисунок 2.11 – ключі безпеки WP за замовченням
Вісім ключів можуть бути згенеровані рандомно на сайті WordPress Salt Keys
Generator [13] (рис.2.12).
Рисунок 2.12 – генеровані криптографічні ключі та сіль
Генеровані ключі безпеки (рис.2.12 ) вставляємо в файл конфігурації. Надалі, в
процесі експлуатації сайту в складі порталу дані ключі безпеки можна періодично
оновлювати цим же способом.
2.4 Механізми фіксації інцидентів безпеки спроб НСД до web-порталу
Журнал логів зберігається в файлі з ім'ям debug.log в каталозі вмісту сайту wp-
content на сервері хостинг-провайдера. Але для аналізу подій, що журналюються в
даному файлі і дозволяють виробити підхід щодо проектування механізму
автентифікації слід мати доступ до нього. Один із способів перегляду і очищення
журналу - прямий доступ до цього файлу.
2.4.1 Ввімкнення створення файлу журналювання подій на сайті
Щоб включити створення лог-журналу для сайту на WordPress, потрібно внести
зміни в системний файл wp-config.php, який розташований на сервері хостингу. Для
цього використаємо такий алгоритм дій:
1. Запускаємо файловий менеджер і підключаємося до віддаленого сервера за
допомогою свого облікового запису, який надає хостинг-провайдер.
2. Переходимо до кореневого каталогу, де встановлений сайт.
3. Робимо резервну копію файлу wp-config.php, щоб відновити систему після
завершення налагодження.
4. Відкриваємо файл wp-config.php на віддаленому сервері та редагуємо рядки, які
відповідають за створенням логів так як показано на рисунку 2.13 :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
Більшість сайтів на WordPress вже мають запис для константи WP_DEBUG,
встановлену в значення false, тому потрібно змінити це значення на true. Рядок з
WP_DEBUG_LOG може бути відсутнім, тому його необхідно додати. Даний
параметр активує створення журналу логів для сайту. Константа
WP_DEBUG_DISPLAY, встановлене значення false, дозволяє приховати запис логів
від відвідувачів сайту (рис.2.13).
Рисунок 2.13 – виконане налаштування в конфігураційному файлі для
включення створення лог-журналу для сайту
Після того як запис логів активований, слід перейти до каталогу вмісту сайту на
WordPress (папка wp-content) та відкрити файл журналу debug.log. Наступним кроком
необхідно перейти в кінець файлу і знайти рядки з мітками часу, відповідними
недавнім діям над сайтом.
Отже, в результаті проведених налаштувань, кожного разу, коли виникає
попередження або помилка в роботі сайту, WordPress генерує повідомлення, яке
записується в журнал логів з відміткою часу в форматі UTC.
Фіксувати дії користувачів на предмет спроб створення нових користувачів або
відслідковування підозрілої активності можна за допомогою плагіну WP Activity Log
або Simple History.
Нижче наведено приклад, який показує зафіксовані спроби отримання доступу
до сайту на хостингу WP зловмисником (рис. 2.14).
Рисунок 2.14 - зафіксовані спроби отримання доступу до сайту на хостингу WP
Як видно з рисунка 2.14, користувач з ip адресою 124.104.31.203 проявляє
підозрілу мережеву активність на сторінці авторизації. Даний користувач намагався
підібрати логін і пароль для доступу до адміністративної панелі (файл wp-login.php).
Після декількох спроб його IP-адресу було заблоковано сервісом хостингу.
Отже, найбільш вразливим елементом механізму авторизації до порталу є
доступ до панелі адміністратора, отримавши який зловмисник може порушити
цілісність інформації ресурсу (змінити або видалити текстову, графічну або
мультимедійну інформацію, впровадити на сайт шкідливе ПЗ, що буде
завантажуватися на ПК відвідувачів тощо), порушити її доступність (заблокувати
виконання сайту на сервері тощо).
Для захисту доступу до панелі адміністратора можна розробити декілька
варіантів модифікації процедури авторизації, наприклад:
1. Встановлення обмеження доступу по IP-адресі.
Даний варіант особливо прийнятний, якщо авторизація відбувається з
постійної локальної підмережі і необхідно обмежити доступ для тих, хто
намагається авторизувати доступ до сайту з інших підмереж та мережі Інтернет.
Фактично, використання даного методу дозволить змінити адресу сторінки
авторизації в панелі адміністратора.
2. Захист авторизації у вигляді спеціального одноразового коду.
Подібний захист необхідний в тому випадку, якщо необхідно ускладнити
перебір паролів у зв'язку з тим, що сайт даного Інтернет-порталу розрахований
на багато користувачів, і сторінку авторизації потрібно тримати відкритою і
загальновідомою (сайт має елементи соціальної мережі, форуму, блогохостинга,
коментування тощо).
Переваги вищевказаних методів в тому, що вони надають простий і необхідний
мінімум безпеки для доступу до порталу при авторизації. Такі методи доступні в
більшості із сучасних систем керування вмістом у WordPress. Але якщо необхідне
комплексне рішення по захисту сайту, то ним може стати використання спеціальних
плагінів. В той же час, обмеження доступу до адімністраторської панелі по IP
пов’язано з необхідністю редагувати конфігураційний файл .htaccess, але в зв’язку з
тим, що IP адреса це фактично адреса підмережі IP, яку надає Інтернет-провайдер, то
даний шлях не завжди є зручним для компаній. Оскільки адмініструвати сайт буде
особа, що не має відповідної квалфікації для налаштування, оберемо в якості базового
механізму авторизації ввімкнення створеня файлу журналювання подій, який
описаний у пункті 2.4.1.
Висновки до розділу 2
Після збору інформації зі звітів щодо частоти використання та кібератак на різні
системи управління сайтами стало відомо, що платформа WordPress є не тільки одною
з найпопулярніших, а й одною з найатакованіших. Згідно звітів по безпеці,
зловмисники атакують сайти, які були створені на платформі WordPress близько
950000 разів за хвилину.
У розділі проаналізовано 17 основних видів загроз безпеці, серед яких
найкритичніше – міжсайтингове виконання сценаріїв (XSS), SQL-ін'єкції, DoS/DDoS
атаки, перебір паролів (Brute Force) та обхід авторизації.
Відповідно до вимог НД ТЗІ 2.5-004-99 сформовано функціональний профіль
захищеності механізму авторизації. Web-портал належить до АС 3-го класу і має
необхідність передачі інформації через незахищене середовище. Обрано профіль
комплексного захисту підприємства – 3.КЦД.1.
Для реалізації та тестування обрано OpenServer, як локальний сервер на базі
Windows з підтримкою сервера – Apache/NginX, мови – PHP, системи управління
базами даних – MySQL та вбудованих інструментів. Виконано початкову
ініціалізацію системи з налаштуванням параметрів авторизації, зміною імені
адміністратора на оригінальне замість стандартного «admin». Модифіковано ключі
безпеки WordPress шляхом генерації унікальних криптографічних ключів та солі за
допомогою WordPress Salt Keys Generator, що впливає на надійніст шифрування
файлів-cookie.
У конфігураційному файлі wp-config.php налаштовано:
- WP_DEBUG,
- WP_DEBUG_LOG
- WP_DEBUG_DISPLAY
для активації журналу логів, який посприяв у виявленні спроби несанкціонованого
доступу з IP-адреси 124.104.31.203 до сторінки авторизації методом підбору паролів.
Аналіз інцидентів показав, що найбільш вразливою точкою є доступ до панелі
адміністратора. При компроментації можливе порушення конфіденційності,
цілісності та доступності інформації web-порталу.
Сформульовано два основні підходи до модифікації процедури авторизації:
обмеження доступу по IP-адресі та використання спеціальних одноразових кодів.
Результати досліджень проведених у другому розділі роботи створюють
необхідну методологічну та технічну базу для проектування та реалізації ефективного
механізму авторизації, який задовольнятиме сучасні вимоги інформаційної безпеки,
відповідатиме діючим нормам, законам та положенням стосовно безпеки інформації,
а також враховуватиме реальні загрози для web-порталу підприємства VRealSoft.
РОЗДІЛ 3 РОЗРОБКА ТА НАЛАШТУВАННЯ МЕХАНІЗМІВ АВТОРИЗАЦІЇ
ЗАХИЩЕНОГО WEB-ПОРТАЛУ
З огляду на обрану платформу реалізації web-порталу, аналізу статистики,
результати спроб отримання доступу до панелі адміністрування сайтів порталу та
виявлення найбільш вразливих елементів механізму авторизації до адміністративної
панелі порталу реалізуємо модифікації процедури авторизації, які покращать
захищеність даного механізму.
3.1 Базові механізми автентифікації адміністратора на порталі
При розробці та конструюванні порталу розробник має єдиний базовий
механізм автентифікації – форма авторизації на сайті наступного вигляду (рис.3.1):
Рисунок 3.1 – стандартна панель авторизації адміністратора сайту
У випадку коректності введених авторизаційних даних адміністратор успішно
входить на сайт, після чого йому надаються права, що відповідають рівню
повноваженнь його облікового запису. Наприклад, адміністратор web-порталу
VRealSoft входить до dashboard CMS WordPress під іменем VA_cybersec.
Далі той чи інший авторизований користувач сайту або порталу чи окремого
сервісу може переглядати web-контент в браузері, або перейти в налаштування та
модифікувати окремі сайти порталу, наприклад, як наведено на рис. 3.2.
Рис.3.2 – перегляд та тестування роботи створеного сайту авторизованим
користувачем сервісу
3.2 Проектування та налаштування складових механізму автентифікації
захищеного web-порталу
Після створення та конфігурації налаштувань базового механізму авторизації
адміністратора даного web-порталу для підвищення захищеності здійснюємо наступні
кроки.
3.2.1 Захист сайту на WordPress
Захист сайту на WordPress починається з елементарного – створення
облікового захисту користувача з високими налаштуваннями безпеки. При
встановленні WordPress, користувачі часто використовують логін, який встановлює
програмне забезпечення за замовчанням, а саме – admin, administrator тощо.
Часто бот-зловмисник або сканер перевіряє це. Знайшовши логін admin,
зловмисник вже має частину необхідної інформації для зламу захисту порталу. Йому
залишиться тільки підібрати пароль.
В даній оновленій версії Wordpress розробники радять відмовлятися від даного
механізму. Тому просто покращуємо рівень стійкості пароля для додатково введеного
користувача (рис.3.3):
Рисунок 3.3 – посилення стійкості пароля базового механізму авторизації для
додатково введеного користувача
3.2.2 Модернізація механізму захисту авторизації від підбору пароля до панелі
адміністратора CMS
Відповідно до статистики інцидентів на платформі WordPress, одним з варіантів
злому сайтів на даній платформі є підбір пароля до панелі адміністратора. Особливо
це актуально для тих сайтів, де відображається логін користувача. В зв’язку з тим, що
логін (admin) при встановлені було змінено на нестандартний, то використаємо
технологію приховування панелі автентифікації WordPress. З цією метою
використаємо плагін який має назву «Defender Security – Malware Scanner, Login
Security & Firewall» [14] (рис.3.4).
Рисунок 3.4 - встановлення плагіну Defender Security – Malware Scanner, Login
Security & Firewall
Даний плагін застосовується з метою протидії брутфорсу (підбору пароля). Його
роль полягає у заміні посилання для доступу до сторінки логіна на унікальне
посилання. Посилання на вхід в систему виглядає так:
https://site.loc/?vRealSoft_adm_log_wp (рис. 3.5).
Рисунок 3.5 – встановлення параметрів налаштувань плагіну Defender Security
– Malware Scanner, Login Security & Firewall
При цьому навіть, якщо логін та пароль відомі, але посилання на сторінку
авторизації – невідоме, то потрапити на панель авторизації не вийде. Тобто,
теоретично, якщо зловмисник або бот підбере пароль, доступ до сайту для нього все
одно буде закритий, а спроба зламати сайт фіксуватиметься автоматично на хостингу.
Після додавання захисного параметру, який відповідає за перенаправлення
трафіку, при спробах зайти на стандартну сторінку авторизації, зловмисника буде
перенаправлено на обраний нами інший сайт (рис.3.6) стандартна сторінка логіна стає
недоступна, і ботам або зловмиснику доведеться шукати сторінку авторизації перед
тим як почати підбирати паролі. Отже, налаштування плагіну закінчено.
Рисунок 3.6 – встановлення параметрів налаштувань плагіну Defender Security
– Malware Scanner, Login Security & Firewall для перенаправлення трафіку
3.2.3 Введення до механізму авторизації двофакторної автнетифікації
В зв’язку з підвищеними вимогами щодо захисту процесу автентифікації до
панелі адміністратора доступу до порталу, введемо двофакторну автентифікацію для
механізму автентифікації захищеного порталу.
Двофакторна аутентифікація (2FA) - це технологія забезпечення захисту
інформації, який вимагає від користувачів надання двох засобів ідентифікації перед
тим, як отримати доступ до свого облікового запису
Таким чином, для автентифікації необхідно пройти два рівні безпеки - це пароль
і унікальний спеціальний код, створений за допомогою програми автентифікації,
зазвичай встановленої на смартфоні. Дві найпопулярніші програми аутентифікації для
схем типу 2FA – це Google Authenticator [15] та Microsoft Authenticator [16].
У нашому випадку, раніше встановлений плагін Defender Security – Malware
Scanner, Login Security & Firewall має також інструмент «2FA», тож встановлювати
додаткові плагіни не потрібно. Робимо активною кнопку активації двофакторної
автентифікації щоб зайти у налаштування і обираємо, для яких ролей користувачів ця
автентифікація буде доступна, а для кого ще й обов’язкова У зв’язку з тим, що доступ
до порталу відповідно до політики безпеки підприємства обмежений, то обираємо
наявність такої двофакторної автентифікації тільки для адміністраторів і редакторів
(довірених осіб) (рис.3.6). Після цього працюємо з налаштуваннями інших функцій,
таких як «відображення назви у додатку» (рис.3.7); функції входу через код з
електронної пошти, на випадок якщо у користувача немає змоги використовувати
додаток і навіть кнопку для завантаження обраної нами програми (Google
Authenticator) з Play Market або AppStore (рис.3.8).
Рисунок 3.6 – налаштування використання 2FA для різних ролей користувачів
у плагіні Defender Security – Malware Scanner, Login Security & Firewall
Рисунок 3.7 – налаштування відображення назви в додатку
Рисунок 3.8 – інші додаткові налаштування двофакторної автентифікації
Після виконання усіх налаштувань, щоб конфігурації вступили в силу,
обов’язково натискаємо кнопку зберегти (рис.3.9), яка знаходиться у не дуже
зручному та помітному місці, що може викликати труднощі у нових користувачів.
Рисунок 3.9 – Збереження налаштувань
Слід зауважити, що в даному плагіні немає можливості обирати за яким
криптографічним алгоритмом буде виконуватись процедура, оскільки алгоритм
HOTP буде задіяний лише у випадку двофакторної автентифікації за допомогою
електронної пошти (рис.3.10). За замовчуванням буде використовуватись
криптографічний алгоритм ТОТР [17]. Даний криптографічний алгоритм
призначений для створення тимчасових одноразових паролів для
захищеної автентификації.
Рисунок 3.10 – Випадок, що передбачає використання HOTP
Для генерування криптографічного одноразового ключа у випадку
автентифікації адміністраторів та редакторів користувачам необхідно буде спочатку
встановити програму для генерування на свій мобільний пристрій (рис.3.11).
Користувачі можуть власноруч знайти необхідну програму, або ж знайти посилання
для завантаження на сторінці авторизації. Для того, щоб увійти на сайт або
скористатися послугами сервісу, потрібно ввести ім'я користувача та пароль,
запустити додаток Google Authenticator і ввести в спеціальне поле згенерований
одноразовий пароль.
Рис.3.11 – встановлена програма Google Authenticator , що реалізує
генерування одноразових паролів для другого фактору автентифікації
При встановленні за замовчуванням використання 2FA у обліковому записі
адміністратора необхідно зайти в налаштування та зробити активними кнопки як
показано на рисунку 3.12
Рисунок 3.12 – встановлення 2FA за замовчуванням для облікового запису
адміністратора
Після цього WordPress дасть QR-код, який необхідно відсканувати у Google
Authenticator для того щоб додати сайт в додаток і запитає 6-значний пароль з додатку
для підтвердження збереження змін як показано на рисунку 3.13.
Рисунок 3.13 – додавання сайту в Google Authenticaticator і використання коду для
збереження змін
Google Authenticator являє собою додаток для двоетапної аутентифікації за
допомогою Time-based One-time Password Algorithm (TOTP) і HMAC-based One-time
Password Algorithm (HOTP) від Google. Сервіс реалізує алгоритми зазначені в RFC
6238 і RFC 4226 [18].
RFC 4226 – це стандарт в якому описано як саме діє алгоритм HOTP (HMAC),
який використовується у алгоритмі TOTP.
RFC 6238 – це стандарт в якому описано як саме діє алгоритм TOTP (новіший і
вдосконаленіший).
Для проведення авентифікації, сайт надає загальний секретний ключ
користувачеві у вигляді 6-ти або 8-ми розрядного одноразового цифрового паролю,
який доступний лише у додатку Google Authenticator протягом короткого терміну.
Якщо за визначеного терміну користувач не встигає використати даний тимчасовий
код, то він автоматично оновлюється. Такий унікальний код буде використовуватися
для всіх майбутніх входів на сайт.
Для користувачів, для яких ввімкнена дана опція, буде запитуватися
одноразовий код при спробі входу.
Таким чином, двофакторна аутентифікація, гарантує, що знання зловмисником
логіна або пароля не є достатнім для злому облікового запису.
Зловмисник також повинен знати секретний ключ або мати фізичний доступ до
пристрою з Google Authenticator. Альтернативним шляхом для атаки на дану схему є
атаки типу MITM (man-in-the-middle) – атака, коли зловмисник таємно перехоплює
комунікацію між двома сторонами і краде чи модифікує дані [19], але для цього ПК, з
якого відбувається автентифікація до даного сайту необхідно інфікувати трояном –
шкідливе програмне забезпечення, яке маскують під безпечну програму з метою
отримати доступ до системи користувача або певної інформації [20]. Як результат -
ім'я користувача, пароль і одноразовий код можуть бути перехоплені, щоб потім
ініціювати свій власний сеанс входу на сайт або ж відслідковувати та змінювати
інформацію між користувачем та сайтом.
3.2.4 Обмеження спроб авторизації в адмінпанель WordPress
Для обмеження кількості спроб авторизації в адмінпанель WordPress
скористаємося плагіном Login Lockdown & Protection [21].
Даний плагін дозволяє заблокувати IP-адреси на деякий час, якщо протягом
певного часу було кілька невдалих спроб авторизації. Приклад реалізації такої
активності зловмисником наведено в розділі 2.
Використання даного плагіну посилить захист від брутфорса (підбору логіна і
пароля) у механізмі автентифікації.
Після встановлення модуля (рис.3.14) та його активації переходимо до
процедури його налаштування.
Рисунок 3.14 – Встановлення плагіну Login Lockdown & Protection
Стандартні налаштування (рис.3.15) нам не підходять, а отже будемо змінювати
на необхідні нам умови (рис.3.16) .
Рисунок 3.15 – стандартні налаштування модуля Login Lockdown & Protection
у механізмі автентифікації
Як показано на рисунку 3.15 даний модуль містить 7 основних пунктів
налаштувань, які нас цікавлять:
- Maх Login Retries (максимальна кількість спроб авторизації після яких
даний IP буде заблоковано). Залишимо рівним 5.
- Retry time perid Restriction (Час між спробами авторизації). Встановимо
його рівним 10 хвилин. Тобто, в разі невдалої першої спроби авторизації на
сайті, користувачеві (або зловмиснику треба буде чекати 10 хв наступної
спроби).
- Налаштування Lockout length говорить про те, наскільки буде заблоковано
сайт після того, як будуть вичерпані дозволені спроби авторизації. Встановимо
номер даного параметру 60 хвилин.
- Спроба неправильного вводу логіну не вважається помилкою (Lockout
Invalid Usernames). З точки зору зловмисника за умови відсутності логіну в його
базі він буде використовувати підбір, тому правильним буде змінити даний
параметр на Yes.
- Mask Login Errors? – приховує повідомлення про неправильний пароль чи
логін. Ввімкнемо Yes для того, щоб система не видавала потенційному
зловмиснику повідомлення про те, що він ввів неправильний логін або пароль.
Тому для нього тепер буде показано лише повідомлення про те,що загалом
спроба авторизації була невдалою
- Show Credit Link? Пов’язано з рекламуванням даного плагіну у себе на
сайті. Відмовимося від цього, адже зайве посилання про те, який ми саме плагін
використовуємо може дати порушнику шанс знайти його описані вразливості.
В результаті отримаємо наступні налаштування модуля Login Lockdown &
Protection, які відповідають політикам безпеки для розроблюваного механізму
автентифікації (рис. 3.16).
Рисунок 3.16 – підсумкові налаштування модуля Login Lockdown & Protection
механізму автентифікації
Не варто забувати, що посилення механізмів автентифікації за допомогою
модернізації механізму авторизації від підбору пароля до панелі адміністратору CMS,
введення до механізму авторизації двофакторної автнетифікації, обмеження спроб
авторизації в адмінпанель WordPress або відключення доступу до адміністративної
панелі інколи можуть не давати результатів. Особливо, якщо зловмисник має
достатньо спроб або часу на реалізацію НСД. Якщо доступ до адміністративної панелі
сайту має більше однієї особи (в даному випадку – адміністратор і редактор), і до того
ж немає можливості змінювати адресу панелі оператора – захистити її від спроб НСД
можна за допомогою модуля reCaptcha(рис.3.17).
Рисунок 3.17 – приклад використання reCaptcha
3.2.5 Захист автентифікації для сторонніх користувачів порталу
У зв’язку з тим, що створюваний портал містить сервіси підтримки тільки
зареєстрованих користувачів, слід обмежити можливість входу за допомогою
механізму авторизації. Тобто, виникає задача захисту веб-сайтів даного сервісу
WordPress від записів зі спамом, дозволяючи реальним користувачам авторизуватися
без складнощів та сильно ускладнити можливість ботам підбирати адекватні дані
авторизації. Такі обмеження автентифікації слід використовувати як для входу на
сайт, так і на моменті реєстрації нових користувачів, для запобігання масовому
створенню фейкових акаунтів ботами.
З даною метою використаємо плагін Advanced Google reCAPTCHA [22]. Для
початку, встановлюємо його (рис.3.18):
Рисунок 3.18 – початок процедури встановлення модуля Google Captcha
Після встановлення модуля Advanced Google reCAPTCHA заходимо у
налаштування для вибору версії, яка буде використовуватися і на яких сторінках. У
нашому випадку це reCaptcha v2, для впровадження якої необхідні ключі API
(рис.3.19).
Рисунок 3.19 – вибір версії reCaptcha
Для того щоб отримати необхідні ключі API необхідно зареєструвати сайт у
гугл, що нам пропонують зробити при переході за посиланням у повідомленні про
необхідність введення ключа сайту і секретного ключа задля збереження змін. На
сайті ми вводимо дані нашого сайту (рис. 3.20) і нехитрим методом отримуємо
необхідні набори символів, які можна скопіювати (рис.3.21).
Рисунок 3.20 – реєстрація сайту в Google
Рисунок 3.21 – отримані ключі, готові до копіювання
Потім скопійовані ключі ми вставляємо у необхідні поля і натискаємо кнопку
«перевірити Captcha» як показано на рисунках 3.22 та 3.23.
Рисунок 3.22 – введені необхідні ключі та перевірка капчі
Рисунок 3.23 – підтвердженяя капчі
Коли капча успішно підтверджена, корегуємо місце її відображення, так як
показано на рисунку 3.24, а саме на сторінці логіну, при реєстрації нового
користувача, при операції відновлення втраченого пароля і при додаванні коментарів.
Капча відображатиметься за замовчуванням для всіх користувачів.
Рисунок 3.24 – налаштування відображення капчі.
У підсумку, форми реєстрації, , відновлення втраченого пароля, прикріплення
коментарів та вікно авторизації отримують форму з капчею, яка доволі серйозно
ускладнить можливості перебору паролів та спроби брутфорсу.
Висновки до розділу 3
У третьому розділі дипломної роботи розроблено та реалізовано комплексний
багаторівневий механізм авторизації захищеного web-порталу підприємства
VRealSoft на базі платформи WordPress з використанням локального web-сервера
OpenServer.
Проаналізовано базовий механізм автентифікації адміністратора і встановлено
що це не є достатнім для забезпечення належного захисту від сучасних загроз.
Розроблено та впроваджено п'ять рівнів захисту механізму авторизації , серед
яких :
- перший рівень захисту – посилення стійкості базового механізму
авторизації, шляхом заміни стандартного логіну «admin» на унікальний, для
ускладнення використання методу підбору облікових даних. Впроваджено
політику складних паролів для відповідності діючим сучасним вимогам та
рекомендаціям.
- другим рівнем захисту – стала модернізація механізму захисту від підбору
пароля до панелі адміністратора системи керування сайтами. Впроваджено
плагін Defender Security – Malware Scanner, Login Security & Firewall, який за
допомогою заміни посилання на унікальне, приховує панель авторизації,
посилання має формат: https://site.loc/?vRealSoft_adm_log_wp . Встановлений
режим перенаправлення трафіку додатково ускладнює зловмисникам доступ до
необхідної сторінки.
- Третім рівнем захисту – стала впроваджена двофакторна автентифікація
(2FA). Налаштовано плагін Defender Security – Malware Scanner, Login Security &
Firewall, а точніше його інструмент 2FA, який використовує алгоритм TOTP,
призначений для створення тимчасових одноразових паролів. Плагін вимагає від
користувачів надання двох засобів ідентифікації(один з яких цей тимчасовий
пароль) перед отриманням доступу до облікового запису.
- Четвертий рівень захисту – це обмеження кількості спроб авторизації. За
допомогою плагіна Login Lockdown & Protection реалізовано інтелектуальну
систему блокування IP-адреси при підозрілій активності та невірно вказаних
облікових даних.
- П’ятим рівнем захисту – є всім відома система CAPCHA. Це захист не від
людей, а від ботів, програм- сканерів і такого іншого. Система інтегрована у
форму реєстрації задля зниження шансів реєстрації бот- і спам- аккаунтів. У
формі авторизації форма запобігає автоматизованим спробам підбору пароля.
Проведено тестування розробленого механізму авторизації в середовищі
локального web-сервера OpenServer, що підтвердило працездатність усіх компонентів
та їх сумісність між собою а от же і довело, що поставленої мети досягнуто.
ВИСНОВКИ
В роботі було проаналізовано та виділено :
- інформаційну та організаційну структуру підприємства та його ІКС, в
якій виділено суб’єкти та об’єкти доступу та модель взаємодії елементів
захищеного web – порталу;
- статистику вразливостей платформи web-порталу, їх характер.
Сформульовано функціональний профіль захищеності порталу та обрано
платформу реалізації, на якій було:
- проведено налаштування системи журналювання інцидентів;
- отримано початкову статистику потенційних спроб НСД.
В результаті були:
- спроектовані та налаштовані додаткові механізми авторизації, які
дозволяють посилити стійкість парольного захисту та значно ускладнити підбір
паролю;
- додано механізм двофакторної авторизації;
- налаштовано та встановлено модуль обмеження спроб авторизації до
адмінпанелі платформи WordPress;
- передбачено захист автентифікації для сторонніх користувачів порталу.
Таким чином, створений механізм авторизації відповідає вимогам, щодо захисту
інформації WEB-сторінки від несанкціонованого доступу, що встановлюється
загальними вимогами НД ТЗІ 2.5-010-2003 [23].
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
1. Офіційний сайт ТОВ VRealSoft [Електронний ресурс] // VRealSoft. –
Режим доступу: https://vrealsoft.com/ (дата звернення: 01.12.2025).
2. Розуміння відмінностей між комутаторами рівня 3 і маршрутизаторами
[Електронний ресурс] // Fiberroad. – Режим доступу:
https://fiberroad.com/uk/resources/tech-notes/understanding-the-differences-between-
layer-3-switches-and-routers/ (дата звернення: 01.12.2025).
3. Офіційна документація NGINX [Електронний ресурс] // NGINX. – Режим
доступу: https://docs.nginx.com/ (дата звернення: 01.12.2025).
4. Лекційні матеріали Львівського національного технічного університету
[Електронний ресурс] // Львівський національний політехнічний
університет. – Режим доступу:
https://elib.lntu.edu.ua/sites/default/files/elib_upload/teoretic/lec7.htm(дата звернення:
01.12.2025).
5. Цивільний кодекс України від 16.01.2003 № 435-IV (п.2 ст.432)
[Електронний ресурс] // Верховна Рада України. – Режим доступу:
https://zakon.rada.gov.ua/laws/show/435-15#Text (дата звернення: 01.12.2025).
6. Статичні та динамічні веб-сайти [Електронний ресурс] // ArmedSoft. –
Режим доступу: https://armedsoft.com/ua/blog/statychni-ta-dynamichni-web-sayty (дата
звернення: 01.12.2025).
7. Повний посібник з безпеки WordPress [Електронний ресурс] // CyberSet. –
Режим доступу: https://cyberset.com.ua/advanced/protection/wordpress-security-guide/
(дата звернення: 01.12.2025).
8. WordPress security & hardening, the definitive guide [Електронний ресурс]
// WP White Security. – Режим доступу: https://melapress.com/wordpress-security/ (дата
звернення: 01.12.2025).
9. НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації в
комп'ютерних системах від несанкціонованого доступу. – Київ : Держспецзв'язку
України, 1999. – 53 с.
10. НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні
функціональні профілі захищеності оброблюваної інформації від несанкціонованого
доступу. – Київ : Держспецзв'язку України, 1999. – 32 с.
11. Класифікація автоматизованих систем і стандартні функціональні профілі
захищеності оброблюваної інформації [Електронний ресурс] // Тернопільський
національний технічний університет ім. І. Пулюя. – Режим доступу:
https://studfile.net/preview/9649922/page:2/ (дата звернення: 01.12.2025).
12. Офіційна документація OpenServer [Електронний ресурс] // Панель
OpenServer. – Режим доступу: https://ospanel.io/docs/ (дата звернення: 01.12.2025).
13. WordPress Salt Keys Generator [Електронний ресурс]. – Режим доступу:
https://api.wordpress.org/secret-key/1.1/salt/ (дата звернення: 01.12.2025).
14. Плагін Defender Security – Malware Scanner, Login Security & Firewall
[Електронний ресурс] // WPMU DEV. – Режим доступу:
https://wordpress.org/plugins/defender-security/ (дата звернення: 01.12.2025).
15. Google Authenticator [Електронний ресурс] // Google. – Режим доступу
https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=
uk (дата звернення: 01.12.2025).
16. Microsoft Authenticator [Електронний ресурс] // Microsoft. – Режим
доступу: https://www.microsoft.com/uk-ua/security/mobile-authenticator-app (дата
звернення: 01.12.2025).
17. Криптографічний алгоритм TOTP [Електронний ресурс] // Wikipedia. –
Режим доступу: https://uk.wikipedia.org/wiki/Time-based_One-time_Password_algorithm
(дата звернення: 01.12.2025).
18. GitHub - google/google-authenticator: Open source version of Google
Authenticator (except the Android app) (неопр.). GitHub. Google. — «These
implementations support the HMAC-Based One-time Password (HOTP) algorithm specified
in RFC 4226 and the Time-based One-time Password (TOTP) algorithm specified in RFC
6238».
19. MITM [Електронний ресурс] // CyberSet. – Режим доступу:
https://cyberset.com.ua/beginners/network/mitm-ataka-sho-tse-take-ta-yak-zakhystytysya/
(дата звернення: 01.12.2025).
20. Троян [Електронний ресурс] // Eset. – Режим доступу:
https://www.eset.com/ua/support/information/entsyklopediya-
zahroz/troyan/?srsltid=AfmBOoolbAYdpWC6hqCwuTJt4PY2a063ZaOQ2Xf1VtLJxv3p
WZTOvVtm (дата звернення: 01.12.2025).
21. Плагін Login Lockdown & Protection [Електронний ресурс] // WebFactory.
– Режим доступу: https://uk.wordpress.org/plugins/login-lockdown/ (дата звернення:
01.12.2025).
22. Плагін Advanced Google reCAPTCHA [Електронний ресурс] //Google. –
Режим доступу: https://wordpress.org/plugins/advanced-google-recaptcha/ (дата
звернення: 02.12.2025).
23. НД ТЗІ 2.5-010-2003 ст.8 [Електронний ресурс] //Державна служба
спецзв’язку. – Режим доступу: https://cip.gov.ua/ua/news/normativni-dokumenti-sistemi-
tzi2024 (дата звернення: 02.12.2025).