Захищена система обміну даними на основі клієнт-серверної архітектури

Голопотилюк, Андрій Володимирович

Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/5978

Назва:	Захищена система обміну даними на основі клієнт-серверної архітектури
Автори:	Панаско, Олена Миколаївна Голопотилюк, Андрій Володимирович
Ключові слова:	cистема клієнт-сервер;криптографічний алгоритм;двофакторна автентифікація;токен;хешування;JWT
Дата публікації:	2023
Короткий огляд (реферат):	"Метою виконання кваліфікаційної роботи магістра є визначення рівня теоретичної та практичної підготовки випускника, підтвердження здатності фахово-професійного вирішення задач прикладного характеру на основі здобутих знань, професійних умінь та навичок відповідно до вимог стандартів вищої освіти. Основні завдання роботи: • Визначення основного функціоналу системи; • Дослідження нормативної бази у сфері захисту клієнт-серверних систем; • Пошук та аналіз поширених загроз інформаційній безпеці притаманних клієнт-серверним системам; • Створення структури проекту та визначення задіяних систем захисту; • Створення програмної реалізації що являє собою сервер для обробки та зберігання інформації, та клієнтської частини для взаємодії з сервером; • Тестування розробленої клієнт-серверної системи."
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/5978
Розташовується у зібраннях:	125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем)

Файли цього матеріалу:

Файл	Опис	Розмір	Формат
М_125_Голопотилюк_Панаско.pdf Restricted Access		3.57 MB	Adobe PDF	Переглянути/Відкрити Запит копії

Показати повний опис матеріалу Перегляд статистики

Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
(повне найменування вищого навчального закладу)
Факультет електронних технологій, автотранспорту та машинобудування
(повна назва факультету)

Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки
(повна назва кафедри)

Пояснювальна записка

до кваліфікаційної роботи магістра
(освітньо-кваліфікаційний рівень)

на тему «Захищена система обміну даними на основі клієнт-серверної
архітектури»

Виконав студент 2 курсу, групи БІ-021

Спеціальності 125 - «Кібербезпека»,
освітньої програми «Безпека
інформаційних і комунікаційних
систем»
(шифр і назва спеціальності)
Голопотилюк А.В.
(прізвище та ініціали)
Керівник Панаско О.М.
(прізвище та ініціали)
Рецензент Проценко О.А.
(прізвище та ініціали)

Черкаси 2023
Форма № Н-9.01

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
(повне найменування вищого навчального закладу)
Факультет електронних технологій, автотранспорту та машинобудування
(повна назва)
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки
(повна назва)
Освітньо-кваліфікаційний рівень магістр
(шифр і назва)
Спеціальність 125 – Кібербезпека
(шифр і назва)
Освітня програма "Безпека інформаційних і комунікаційних систем "
(шифр і назва)

ЗАТВЕРДЖУЮ
Завідувач кафедри Палагін В.В.
____________
“ ” 20__ року

З А В Д А Н Н Я
НА ВИПУСКНУ РОБОТУ СТУДЕНТУ

Голопотилюку Андрію Володимировичу
(прізвище, ім’я, по батькові)

1. Тема проекту (роботи) Захищена система обміну даними на основі клієнт-серверної
архітектури _________________________________________________________________________
керівник проекту (роботи) Панаско Олена Миколаївна, к.т.н., доцент_____
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом Черкаського державного технологічного університету
від «10» жовтня 2023 року № 271/04
2. Строк подання студентом проекту (роботи) « » 2023 р.
3. Вхідні дані до проекту (роботи) визначений функціонал системи
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити)
Вступ; розділ 1 Аналіз інформаційної безпеки клієнт-серверної системи; розділ 2 Концепція
програмно-технічної реалізації системи; розділ 3 Реалізація захищеної системи обміну даними на
основі клієнт-серверної архітектури. Тестування системи; Висновки; Список використаних
джерел
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів): мульти
медійна презентація «Захищена система обміну даними на основі клієнт-серверної архітектури»
14 слайдів Плакат 1 – Титульний лист; плакат – 2 Мета та завдання роботи; плакат 3
Актуальність теми; плакат 4 Визначення загальної структури та функціоналу системи; плакат
5 Визначення можливих загроз безпеці системи; плакат 6 Заходи щодо забезпечення безпеки
системи; плакат 7 Схема роботи HTTPS протоколу; плакат 8 Реєстрація та автентифікація;
плакат 9 Робота з токеном; плакат 10 Захист від ін’єкцій; плакат 11 Моніторинг та
журналювання; плакат 12 Тестування розробленої системи; плакат 13 Висновок; плакат 14
Заключний слайд
6. Консультанти розділів проекту (роботи)
Підпис, дата
Розділ Прізвище, ініціали та посада консультанта
завдання видав завдання прийняв
Охорона праці Кожем’якін О.С., старший викладач
кафедри безпеки життєдіяльності

7. Дата видачі завдання _________________

КАЛЕНДАРНИЙ ПЛАН

Строк виконання
№ Назва етапів дипломного
етапів проекту Примітка
з/п проекту (роботи)
(роботи)
1. П ошук і аналіз інформації по заданій темі
2. Н аписання І розділу Аналіз інформаційної безпеки
клієнт-серверної системи
3. Н аписання ІІ розділу Концепція програмно-
технічної реалізації системи
4. Н аписання ІІІ розділу Реалізація захищеної
системи обміну даними на основі клієнт-серверної
архітектури. Тестування системи
5. Н аписання вступу і висновків, складання списку
літератури
6. О формлення пояснювальної записки
7. П одання роботи в ДЕК
8. З ахист роботи в ДЕК

Студент _________________Голопотилюк А.В.
(підпис) (прізвище та ініціали)
Керівник роботи ____________Панаско О.М.
(підпис) (прізвище та ініціали)

ЗМІСТ

ВСТУП ......................................................................................................................... 6
1. АНАЛІЗ ІНФОРМАЦІЙНОЇ БЕЗПЕКИ КЛІЄНТ-СЕРВЕРНОЇ СИСТЕМИ ... 8
1.1 Структура та функціональність системи ........................................................ 8
1.2 Дослідження нормативних документів у сфері захисту клієнт-серверних
систем ...................................................................................................................... 11
1.3 Визначення можливих загроз інформаційній безпеці системи передачі
даних на основі клієнт-серверної архітектури .................................................... 15
1.4 Заходи щодо забезпечення інформаційної безпеки клієнт-серверної
системи .................................................................................................................... 18
Висновки до розділу 1 ........................................................................................... 19
2. КОНЦЕПЦІЯ ПРОГРАМНО-ТЕХНІЧНОЇ РЕАЛІЗАЦІЇ СИСТЕМИ ............ 20
2.1 Реалізація захищеного з’єднання клієнта і сервера ..................................... 20
2.2 Впровадження реєстрації та двофакторної автентифікації ........................ 23
2.3 Використання токену для ідентифікації користувача ................................. 26
2.3.1 Принцип роботи токену, його генерація та перевірка ........................... 28
2.3.2 Вибір криптографічного алгоритму для хешування та створення
цифрового підпису .............................................................................................. 30
2.3.3 Безпечна відправка та збереження токену .............................................. 34
2.3.4 Перевірка токену сервером ....................................................................... 39
2.4 Впровадження заходів спрямованих на захист від ін’єкцій ....................... 41
2.4.1 Робота з базою даних ................................................................................. 43
2.4.2 Перевірка отриманий файлів .................................................................... 47
2.5 Моніторинг та журналювання ....................................................................... 49
2.6 Структура системи .......................................................................................... 52
Висновки до розділу 2 ........................................................................................... 55
3. РЕАЛІЗАЦІЯ ЗАХИЩЕНОЇ СИСТЕМИ ОБМІНУ ДАНИМИ НА ОСНОВІ
КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ. ТЕСТУВАННЯ СИСТЕМИ ................. 57

ЧДТУ.23.22187.002.ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб . Г олопотилюк А.В.
Захищена система обміну Літ. Арк. Акрушів
Перевір. Панаско О.М. 4
95
даними на основі клієнт-
Реценз. Проценко О.А.
серверної архітектури
Н. Контр. Байрак А.В. ЧДТУ. БІ-021
Затверд. Палагін В.В.

3.1 Створення захищеного з’єднання клієнта і сервера .................................... 57
3.2 Створення функціоналу для реєстрації та двофакторної автентифікації
користувача ............................................................................................................. 58
3.3 Генерація, відправка, збереження та перевірка токену ............................... 60
3.4 Реалізація систем захисту від ін’єкцій. Перевірка надісланих .................. 62
файлів ...................................................................................................................... 62
3.5 Впровадження моніторингу та журналювання ............................................ 66
3.6 Огляд структури розробленої системи ......................................................... 67
3.7 Тестування інформаційної безпеки системи ................................................ 70
3.7.1 Важливість тестування, огляд засобів тестування ................................. 70
3.7.2 Результати тестування системи. ............................................................... 72
3.7.3 Аналіз результатів та визначення заходів що до усунення виявлених
загроз .................................................................................................................... 77
Висновки до розділу 3 ........................................................................................... 78
ЗАГАЛЬНІ ВИСНОВКИ .......................................................................................... 79
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 80
Додаток А ................................................................................................................... 81
Додаток Б ................................................................................................................... 92

Арк.
ЧДТУ.23.22187.002.ПЗ
5
Змн. Арк. № докум. Підпис Дата

ВСТУП

В сучасному світі, де обмін даними забезпечує функціонування
суспільства та підприємств, системи обміну даними на основі клієнт-серверної
архітектури являються вкрай важливими для ефективного управління
інформацією. Забезпечення цілісності, конфіденційності та доступності даних
стає домінуючим завданням в умовах високотехнологічного прогресу та
зростаючого обсягу цифрової інформації.
Системи обміну даними на основі клієнт-серверної архітектури
визначаються як невід'ємна частина сучасних інформаційних технологій, яка
забезпечує високоефективний обмін інформацією між різними вузлами мережі.
Важливість цієї архітектури полягає в її здатності сприяти зручності та
швидкості обробки даних, а також у покращенні доступності інформації.
Зокрема, клієнт-серверна архітектура дозволяє створювати системи обміну
даними, які відповідають сучасним вимогам до ефективності та безпеки. Вона
сприяє створенню інтерфейсів, що взаємодіють із клієнтами, забезпечуючи при
цьому централізований та ефективний контроль над обробкою даних на сервері.
Такий підхід робить можливим розширення функціональних можливостей,
вдосконалення масштабованості та підвищення надійності інформаційних
систем.
У наш час, коли обсяг інформації стрімко зростає, розвиток систем обміну
даними на основі клієнт-серверної архітектури є важливим етапом у
забезпеченні ефективної обробки та збереження даних. Ця архітектура стає
ключовою для багатьох галузей, включаючи фінанси, медицину, бізнес та
державні установи. Високий рівень безпеки та швидкодії стають домінуючими
чинниками, які підвищують ефективність роботи та надають можливість легкого
обміну важливою інформацією.
Розробка та удосконалення систем обміну даними на основі клієнт-
серверної архітектури стає необхідністю, оскільки вони не лише сприяють
оптимізації бізнес-процесів, а й забезпечують надійний механізм обробки та

Арк.
ЧДТУ.23.22187.002.ПЗ
6
Змн. Арк. № докум. Підпис Дата

зберігання інформації в умовах сучасного технологічного прогресу. Розвиток
цієї сфери визначає новий рівень можливостей для вирішення завдань,
пов'язаних із забезпеченням інформаційної безпеки та оптимізацією обміну
даними в онлайн середовищі.
Розробка в рамках кваліфікаційної роботи захищеної системи обміну
даними на основі клієнт-серверної архітектури дозволить створити механізм, що
відповідає високим стандартам інформаційної безпеки та ефективності.
Використання передових технологій у сфері криптографії, автентифікації та
мережевих протоколів дозволить побудувати надійний бар'єр для захисту
важливих даних від несанкціонованого доступу.
Метою виконання кваліфікаційної роботи магістра є визначення рівня
теоретичної та практичної підготовки випускника, підтвердження здатності
фахово-професійного вирішення задач прикладного характеру на основі
здобутих знань, професійних умінь та навичок відповідно до вимог стандартів
вищої освіти.
Основні завдання роботи:
• Визначення основного функціоналу системи;
• Дослідження нормативної бази у сфері захисту клієнт-серверних систем;
• Пошук та аналіз поширених загроз інформаційній безпеці притаманних
клієнт-серверним системам;
• Створення структури проекту та визначення задіяних систем захисту;
• Створення програмної реалізації що являє собою сервер для обробки та
зберігання інформації, та клієнтської частини для взаємодії з сервером;
• Тестування розробленої клієнт-серверної системи.

Арк.
ЧДТУ.23.22187.002.ПЗ
7
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 1

АНАЛІЗ ІНФОРМАЦІЙНОЇ БЕЗПЕКИ КЛІЄНТ-СЕРВЕРНОЇ СИСТЕМИ

1.1 Структура та функціональність системи

Система обміну даними на основі клієнт-серверної архітектури в
сучасному світі кібербезпеки відіграє ключову роль у забезпеченні ефективного
та безпечного обміну інформацією між різними сутностями. Цей підхід, в
основному, базується на розділенні функціоналу між клієнтськими та
серверними частинами системи, що дозволяє досягти великої гнучкості та
керованості в обробці даних.
Основна структура системи обміну даними на клієнт-серверній архітектурі
включає дві головні частини:
• Клієнтську. Клієнтська частина відповідає за взаємодію з кінцевим
користувачем, збирання введених даних та передачу їх серверу
• Серверну. Серверна частина, у свою чергу, приймає дані від клієнтів,
обробляє їх, виконує необхідні операції та повертає результати назад
клієнтам.

Рис 1.1 – Загальна схема клієнт-серверної архітектури

Арк.
ЧДТУ.23.22187.002.ПЗ
8
Змн. Арк. № докум. Підпис Дата

Основна функціональність таких систем полягає в обміні даними між
клієнтами та серверами, що забезпечує взаємодію між різними користувачами чи
системами. Клієнти відправляють запити на сервер, а сервер, у свою чергу,
відповідає з необхідною інформацією чи результатами обробки. Це забезпечує
швидкий та ефективний обмін даними, а також дозволяє зменшити навантаження
на клієнтські пристрої.
Розроблена система повинна забезпечувати функціонал для отримання
даних від клієнта, збереження цих даних на сервері для власного користування
та відправки даних іншим клієнтам. Інтерфейс повинен бути достатньо
розвинутим для комфортної взаємодії клієнта із системою.
Модель взаємодії клієнт-сервер визначається шляхом розподілу обов'язків
між клієнтом та сервером, в цьому аспекті розглядають три рівні операцій:
1. Рівень представлення даних, що представляє інтерфейс користувача і
забезпечує відображення даних користувачеві, надає функціонал для
отримання та передачі даних від користувача до серверу;
2. Прикладний рівень, який втілює основну логіку системи та виконує
необхідну обробку інформації;
3. Рівень управління даними, який забезпечує збереження даних та надає
функціонал для доступу до них.
Архітектура дворівневої клієнт-серверної системи реалізується шляхом
взаємодію двох окремих програмних застосунків - клієнтського та серверного.
Зважаючи на розподіл вказаних функцій між цими двома частинами виділяють
дві основні моделі:
1. Модель тонкого клієнта, де логіка системи та управління даними
сконцентровані на сервері. Клієнтська програма відповідає лише за
представлення інформації та отриманні її від клієнта.
2. Модель товстого клієнта, в якій сервер відповідає лише за збереження
даних, а їх обробка та логіка роботи з ними зосереджені на клієнтській
стороні.

Арк.
ЧДТУ.23.22187.002.ПЗ
9
Змн. Арк. № докум. Підпис Дата

Проаналізувавши ці дві моделі можна виділити наступні переваги та
недоліки.
1. Модель тонкого клієнта
1.1 Переваги:
• Централізована логіка. Логіка системи та управління даними
знаходяться на сервері, що робить їх керованими та
централізованими. Можливість зменшення навантаження на
клієнтські пристрої, що може бути важливим у випадку пристроїв з
обмеженою потужністю
• Простота утримання. Клієнтські пристрої не потребують значної
обробки та управління даними, що спрощує утримання системи.
1.2 Недоліки:
• Залежність від сервера. Система може бути чутливою до доступності
сервера, оскільки основна логіка розміщена саме там. Можливі
проблеми при відсутності мережевого з'єднання з сервером.
2. Модель товстого клієнта.
2.1 Переваги:
• Локалізована логіка. Логіка обробки даних та взаємодії з
користувачем розташована на клієнтському пристрої, що може
зменшити навантаження на сервер та пришвидшити відповідь
системи.
• Незалежність від сервера. Збереження даних та виконання основних
операцій може здійснюватися локально, що полегшує роботу
системи при відсутності мережевого з'єднання
2.2 Недоліки:
• Ускладнення при забезпечення безпеки. Комплексніше утримання
системи, оскільки логіка розподілена між сервером і клієнтом.
Потребує більше уваги до безпеки та захисту даних на клієнтських
пристроях.
Зважаючи на функціональність системи та потреби у забезпеченні безпеч-
Арк.
ЧДТУ.23.22187.002.ПЗ
1 0
Змн. Арк. № докум. Підпис Дата

ної передачі, обробки та зберігання даних слід обрати модель тонкого клієнта
при якісь клієнтська сторона буде забезпечувати відображення даних та
отримання їх від клієнта, а серверна сторона буде забезпечувати безпечну
обробку надісланих даних, та їх зберігання.

1.2 Дослідження нормативних документів у сфері захисту клієнт-
серверних систем

Нормативні документи у сфері захисту клієнт-серверних систем
визначають ключові стандарти та вимоги, які допомагають забезпечити високий
рівень безпеки та конфіденційності обміну даними між клієнтом та сервером.
Дослідження цих документів важливо для розуміння сучасних стандартів та
підходів до захисту інформації у цій області.
Для аналізу та подальшого використання при розробці системи слід
використати наступні нормативні документи та відкриті інформаційні джерела:
1. NIST SP 800-53;
2. GDPR;
3. Закон України "Про захист персональних даних";
4. OWASP.
NIST SP 800-53.
NIST SP 800-53 визначає систему контролів безпеки для інформаційних
систем та організацій. Цей документ, випущений Національним інститутом
стандартів і технологій (NIST), є ключовим елементом серії стандартів, які
надають рамки для створення, реалізації та управління програмами забезпечення
інформаційної безпеки.
Проаналізувавши NIST можна виділити наступні аспекти що корисні для
роботи з клієнт-серверними системами:
1. NIST Access Control (AC).
Система контролю доступу (Access Control) NIST визначає правила та
обмеження, які регулюють, як користувачі (клієнти) отримують доступ до
Арк.
ЧДТУ.23.22187.002.ПЗ
1 1
Змн. Арк. № докум. Підпис Дата

ресурсів на сервері. На рівні користувача, система Access Control визначає, які
конкретні дії можуть виконувати користувачі, які типи ресурсів доступні, і які
операції вони можуть виконувати над цими ресурсами.
Ключові елементи:
• Визначення прав доступу до конкретних ресурсів.
• Управління правами користувачів на рівні системи та об'єктів.
• Забезпечення прозорості та аудиту доступу.
• Встановлення політик доступу для окремих користувачів або груп.
• Обмеження дій та операцій, які може виконати користувач.
• Забезпечення конфіденційності та цілісності даних на рівні користувача.
2. NIST Audit and Accountability (AU).
Цей розділ NIST визначає, які дії користувачів та інші події повинні бути
аудитовані для забезпечення слідження та аналізу подій. Визначає дії системи
для забезпечення відстеження та реєстрації цих подій для подальшого аналізу та
виявлення аномалій.
Ключові елементи:
• Аудит основних дій, таких як входження користувачів, доступ до ресурсів
тощо.
• Фіксування інформації про спроби неавторизованого доступу.
• Збереження аудитованих подій у безпечному журналі.
• Забезпечення можливості аналізу та кореляції аудитованих подій.
• Визначення шаблонів та правил для виявлення аномалій та попередження
інцидентів.
3. NIST Security Assessment and Authorization (CA).
Цей розділ NIST встановлює процедури та вимоги до оцінки безпеки
системи перед її запуском в експлуатацію. Визначає процес виявлення
потенційних загроз та забезпечення усунення виявлених проблем перед
впровадженням системи.
Ключові елементи:
• Визначення критеріїв безпеки та стандартів відповідності.

Арк.
ЧДТУ.23.22187.002.ПЗ
1 2
Змн. Арк. № докум. Підпис Дата

• Оцінка системи на відповідність встановленим вимогам безпеки.
• Впровадження заходів для зменшення ризиків та усунення
ідентифікованих уразливостей.
• Введення системи в експлуатацію лише після впевненості у її безпеці та
відповідності встановленим стандартам.
• Постійне оновлення та повторна оцінка безпеки під час експлуатації
системи.
GDPR.
Загальне регулювання з питань захисту даних (GDPR) є законодавчим
актом який регулює обробку та захист особистих даних громадян. Введене в дію
у 2018 році, GDPR встановлює строгі вимоги та стандарти для організацій та
систем які використовують персональні дані клієнтів.
Ключові положення:
• Громадяни мають право отримувати доступ до своїх особистих даних та
дізнаватися, як вони обробляються, забезпечуючи прозорість та контроль
над власною інформацією;
• Організації повинні отримувати явну згоду від клієнтів на обробку їх даних
та надавати зрозумілі повідомлення про цей процес, враховуючи
конфіденційність та прозорість;
• GDPR вимагає від клієнт-серверних систем високого рівня захисту
особистих даних, що охоплює різноманітні заходи безпеки, включаючи
шифрування та заходи проти несанкціонованого доступу;
• Організації повинні забезпечити, щоб клієнти надавали свою згоду на
обробку даних свідомо та добровільно. Повідомлення про це повинно бути
доступним у зрозумілій формі, щоб дати користувачам можливість
прийняти усвідомлене рішення;
• GDPR забезпечує право клієнтів на контроль над своїми особистими
даними. Це включає в себе можливість забороняти обробку або видаляти
свої дані, надаючи їм активну участь у керуванні власною інформацією.
Закон України "Про захист персональних даних".
Арк.
ЧДТУ.23.22187.002.ПЗ
1 3
Змн. Арк. № докум. Підпис Дата

Даний закон регулює правові відносини пов’язані із захистом і обробкою
персональних даних, спрямований на захист прав людини і громадян. Цей закон
поширюється на діяльність з обробки персональних даних із застосуванням
автоматизованих систем.
Ключові положення:
• Визначення суб’єкту та об’єкту відносин пов’язаних з персональними
даними;
• Засади обробки персональних даних
• Вимоги до обробки персональних даних;
• Права суб’єктів персональних даних;
• Обов’язки операторів та суб’єктів персональних даних;
• Механізми захисту персональних даних.
Закон України "Про захист персональних даних" є важливим кроком для
забезпечення конфіденційності та безпеки персональної інформації в Україні, а
його дотримання обов'язкове для усіх суб'єктів обробки персональних даних.
OWASP
OWASP, або Open Web Application Security Project, є некомерційною
організацією, яка об'єднує експертів у галузі кібербезпеки з усього світу. Її ціль
- поліпшення безпеки програмного забезпечення, зокрема, веб-додатків. OWASP
прагне розробляти та розповсюджувати відкриті ресурси, інструменти, та
методології, які допомагають розробникам, тестувальникам та іншим
зацікавленим сторонам вдосконалювати безпеку веб-додатків.
OWASP надає нормативи та керівництва, такі як OWASP Application
Security Verification Standard (ASVS) та OWASP Top Ten, що містять
рекомендації щодо вдосконалення безпеки додатків та уникнення типових
уразливостей.
Application Security Verification Standard (ASVS) визначає рівні безпеки та
вимоги до забезпечення безпеки для додатків.
Основні компоненти ASVS включають:
• Рівні безпеки. Три рівні які представляють різні рівні безпеки системи;
Арк.
ЧДТУ.23.22187.002.ПЗ
1 4
Змн. Арк. № докум. Підпис Дата

• Контрольні точки. Містить перелік контрольних точок безпеки, які
визначаються для кожного рівня безпеки. Ці контрольні точки включають
рекомендації та вимоги до безпеки;
• Вимоги. Кожен контрольний пункт має вимоги безпеки, які розглядають
аспекти, такі як аутентифікація, авторизація, захист сесій, обробка
введених даних та багато інших;
• Використання в тестуванні. ASVS може використовуватися для оцінки
рівня безпеки конкретного додатка та визначення кроків для покращення
безпеки.
Що до OWASP Top Ten то він являє собою писок найбільш поширених
уразливостей та загроз безпеці веб-додатків. Цей перелік може бути
використаний для виявлення потенційних проблем безпеки в клієнт-серверних
системах. Він містить як список загроз так і інформацію про причини настання
загрози, наслідки її виникнення та способи захисту системи від її настання.

1.3 Визначення можливих загроз інформаційній безпеці системи
передачі даних на основі клієнт-серверної архітектури

Визначення можливих загроз інформаційній безпеці при розробці клієнт-
серверної системи є ключовим етапом в процесі створення безпечного та
надійного програмного забезпечення. Цей процес відбувається на основі
визначеної структури розроблюваної системи та її функціоналу. Для визначення
загроз використовуються доступні бази даних загроз які є критичним елементом
в забезпеченні інформаційної безпеки. Ця практика дозволяє усвідомлювати
потенційні небезпеки та вразливості, які можуть бути використані
зловмисниками для несанкціонованого доступу чи атак на інформаційні ресурси.
Проаналізувавши структуру клієнт-серверної системи, її функціональність
та доступні бази даних вразливостей такі як: CVE, NVD, OWASP, виділив
наступний перелік загроз притаманний даній системі:
1. Порушений контроль доступу;
Арк.
ЧДТУ.23.22187.002.ПЗ
1 5
Змн. Арк. № докум. Підпис Дата

Контроль доступу забезпечує дотримання політики таким чином, щоб
користувачі не могли діяти поза межами призначених дозволів. Збої зазвичай
призводять до несанкціонованого розголошення інформації, модифікації чи
знищення всіх даних або виконання бізнес-функцій за межами обмежень
користувача.
Поширені вразливості контролю доступу включають:
• Порушення принципу найменших привілеїв або заборони за
замовчуванням, де доступ має надаватися лише для певних можливостей,
ролей або користувачів, але доступний для всіх;
• Обхід перевірок контролю доступу шляхом зміни URL-адреси (підробка
параметрів або примусовий перегляд);
• Підвищення привілеїв. Діяти як користувач без входу в систему або діяти
як адміністратор, коли ви ввійшли як користувач;
2. Криптографічні збої;
Криптографічні збої є другою за поширеністю загрозою. Зазвичай дані збої
виникають у разі:
• Передавання даних відкритим текстом;
• Використання не захищений протоколів таких як HTTP;
• Використання слабких та застарілих криптографічних алгоритмів або
протоколів;
• Використання застарілих хеш-функцій таких як MD5 або SHA1.
3. Ін’єкції;
Ін’єкції - це тип атак на веб-додатки, спрямований на вставку та виконання
зловмисного коду або команд в джерело даних чи в вихідну HTML сторінку.
Одним із найбільш поширених видів ін'єкцій є SQL-ін'єкції та ін'єкції в коді, такі
як скриптові або кодові ін'єкції.
Вразливість до ін’єкцій виникає у разі коли:
• Дані надані користувачем, не перевіряються, не фільтруються та не
очищаються програмою;
Арк.
ЧДТУ.23.22187.002.ПЗ
1 6
Змн. Арк. № докум. Підпис Дата

• Динамічні запити або непараметризовані виклики без контекстно-
залежного екранування використовуються безпосередньо при роботі з
даними;
• Ворожі дані використовуються в параметрах запитів до бази даних.
4. Ненадійний дизайн;
Незахищений дизайн — це широка категорія, що представляє різні слабкі
сторони, виражені як «відсутній або неефективний дизайн контролю». Дана
загроза виникає у разі некоректно сформованої структури системи та роботи всіх
її систем захисту що може призвести до атаки в обхід працюючих систем захисту
5. Неправильна конфігурація безпеки;
Дана загроза може виникати у разі якщо:
• Ввімкнено або встановлено непотрібні функції (наприклад, непотрібні
порти, служби, сторінки, облікові записи або привілеї);
• Встановлені облікові записи за замовчуванням і їхні паролі залишаються
активними та не змінюються;
• Обробка помилок видає користувачам надто інформативні повідомлення
про помилки;
• Сервер не надсилає заголовки безпеки чи директиви, або для них не
встановлено безпечні значення
6. Помилки ідентифікації та автентифікації;
Підтвердження особи користувача має вирішальне значення для захисту
від атака пов’язаних з автентифікацією. Система може бути вразлива якщо:
• Дозволяє стандартні, слабкі чи занадто короткі паролі;
• Використовує слабкі або неефективні процеси відновлення облікових
даних та забутих паролів;
• Використовує звичайний текст або слабко хешовані дані паролів;
• Має відсутню багатофакторну автентифікацію;
• Розкриває ідентифікатор сеансу в URL.
7. Відсутність моніторингу.

Арк.
ЧДТУ.23.22187.002.ПЗ
1 7
Змн. Арк. № докум. Підпис Дата

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

1.4 Заходи щодо забезпечення інформаційної безпеки клієнт-серверної
системи

Впровадження ефективних заходів захисту є критичним завданням для
запобігання несанкціонованому доступу, втраті даних чи можливим атакам на
систему. Проаналізувавши структуру системи обміну даних на основі клієнт-
серверної архітектури, визначивши потрібний функціонал, та визначивши
основні загрози інформаційній безпеці системи, розробив наступні заходи щодо
забезпечення безпеки системи:
1. Використання HTTPS для створення захищеного та зашифрованого
з’єднання клієнта з сервером. Використовуваний в ньому SSL або TLS
криптографічний протокол забезпечить шифрування: URL запиту, шляху
та назви ресурсу, параметри запиту, заголовки та кукі;
2. Двофакторна аутентифікація. Впровадження додаткового рівня безпеки
під час входу в систему;
3. Використання токену для ідентифікації користувача. Реалізація генерації
токену сервером, його обмін та обробка при отриманні;
4. Хешування паролів. Використання надійних алгоритмів хешування що
унеможливлять доступ до облікового запису користувача навіть після
отримання паролю зловмисником;
5. Захист від ін’єкцій. Впровадження систем для дослідження отриманих від
клієнта запитів. Реалізація перевірки надісланих параметрів очікуваному
формату. Використання програмних рішень що забезпечують створення

Арк.
ЧДТУ.23.22187.002.ПЗ
1 8
Змн. Арк. № докум. Підпис Дата

параметризованих запитів до бази даних;
6. Перевірка отриманих файлів. Реалізація функцій для обробки та перевірки
на вміст вірусів файлів що надсилаються на сервер для приватного
користування чи передачі іншим користувачам;
7. Моніторинг та журналювання. Моніторинг всіх запитів що надходять на
сервер та збереження даних про ці запити. Відслідковування аномальної
активності;
8. Безпечний дизайн та структура системи. Створення безпечної та надійної
структури взаємодії всіх систем захисту. Унеможливлення обходу наявний
систем захисту.

Висновки до розділу 1

Під час написання даного розділу була розглянута структура та
функціональність системи обміну даними на основі клієнт-серверної
архітектури. Основна увага була приділена двом головним частинам системи:
клієнтській та серверній. Клієнтська частина відповідає за взаємодію з кінцевим
користувачем, збір введених даних та їх передачу. Серверна частина, в свою
чергу приймає дані від клієнтів, обробляє їх та повертає результати.
Крім того розділ охопив дослідження нормативної бази включаючи
стандарти NIST SP 800-53, GDPR, Закон України «Про захист персональних
даних» та OWASP. Аналіз цих документів та наявних у вільному доступі баз
даних загроз, став основою для визначення подальших заходів щодо
забезпечення інформаційної безпеки системи.
Таким чином, перший розділ надав відомості про структуру,
функціональність системи, та визначив основні заходи які допоможуть
забезпечити інформаційну безпеку клієнт-серверні системі.

Арк.
ЧДТУ.23.22187.002.ПЗ
1 9
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 2

КОНЦЕПЦІЯ ПРОГРАМНО-ТЕХНІЧНОЇ РЕАЛІЗАЦІЇ СИСТЕМИ

2.1 Реалізація захищеного з’єднання клієнта і сервера

Реалізація захищеного з’єднання є основним аспектом у забезпеченні
інформаційної безпеки клієнт-серверної системи. На сьогодні найкращим
рішенням для цього є застосування HTTPS.
HTTPS (Hypertext Transfer Protocol Secure) є протоколом передачі даних в
мережі Інтернет, який використовується для забезпечення безпечного та
зашифрованого обміну інформацією між веб-сервером та користувачем.
Основною метою HTTPS є надання додаткового рівня безпеки для передаваних
даних, забезпечуючи конфіденційність, цілісність та аутентифікацію.

Рис 2.1 – Схема роботи HTTPS протоколу

Принцип роботи системи з використанням HTTPS з наступних етапів:
1. Початок з’єднання;
Клієнт починає взаємодію із сервером надсилаючи запит на захищене
з’єднання за допомогою протоколу HTTP який в подальшому потрібно
захистити;

Арк.
ЧДТУ.23.22187.002.ПЗ
2 0
Змн. Арк. № докум. Підпис Дата

2. Обробка запиту сервером надсилання відповіді;
Сервер отримує запит від клієнта та підтверджує готовність
використовувати HTTPS. Сервер відправляє клієнту свій сертифікат та
публічний ключ а також вибирає криптографічний алгоритм який буде
використовуватися при подальшому обміні даними. Зазвичай використовується
криптографічний алгоритм AES так як він є одним із найбільш захищений
симетричних алгоритмів;
3. Перевірка сертифікату та відправка ключа шифрування;
Після отримання відповіді від сервера клієнт проводить перевірку
сертифікату на валідність. Це включає перевірку того чи сертифікат підписаний
довіреним центром сертифікації, чи не минув термін дії сертифікату та чи
відповідає він домену сервера. Якщо сертифікат валідний клієнт генерує та
надсилає серверу ключ для симетричного шифрування. Цей ключ буде
використовуватися для шифрування та розшифрування даних.
4. Встановлення безпечного з’єднання
Після того як перевірка сертифікату пройдена та ключі для симетричного
шифрування надіслані, обидві сторони підтверджують готовність до створення
захищеного з’єднання. Всі подальші запити від клієнта та відповіді від сервера
будуть шифруватися та розшифровуватися при отриманні.
Забезпечення конфіденційності даних які передаються між клієнтом і
сервером під час обміну інформацією забезпечується за допомогою SSL та його
більш розвиненим варіантом TLS. Вони використовуються симетричні та
асиметричні протоколи на етапах встановлення безпечного з’єднання. SSL/TLS
дозволяє клієнту і серверу перевірити автентичність одне одного під час
початкового з’єднання, забезпечують безпечне передавання сертифікату і ключа
для перевірки їх клієнтом. Після перевірки валідності сертифікату і надсиланні
ключа для симетричного шифрування, SSL/TLS забезпечують безпечне
передавання цього ключа серверу з використанням протоколу Ephemeral Diffie-
Hellman (ECDHE). Щодо подальшого шифрування даних при обміні то
протоколом передбачено використання симетричного криптографічного

Арк.
ЧДТУ.23.22187.002.ПЗ
2 1
Змн. Арк. № докум. Підпис Дата

алгоритму, зазвичай використовується алгоритм AES.
AES (Advanced Encryption Standard) – є одним з найпопулярніших
симетричних алгоритмів шифрування, прийнятий як американський стандарт
шифрування урядом США. Алгоритм має фіксовану довжину у 128 біт, а розмір
ключа може приймати значення 128, 192 або 256 біт. Шифрування за даним
алгоритмом відбувається у чотири етапи:
1. subBytes().
На цьому етапі відбувається обробка байтів та відбувається нелінійна
заміна на основі таблиці. Виконання таких дій забезпечує нелінійність
алгоритму;

Рис 2.2 – Операція заміни байтів

2. shiftRows().
Після заміни байтів відбувається циклічний зсув отриманої таблиці на r
байтів по горизонталі, число r визначається в залежності від номеру рядка, для
першого рядка r=0, для другого r=1 і так далі;
3. mixcolumns()
Це етап виконує змішування чотирьох байтів кожної колонки отриманої
таблиці, використовуючи для цього зворотну лінійну трансформацію. Під час
виконання даного етапу стовпці таблиці множаться на матрицю.

Рис 2.3 – Матриця для 128-бітного ключа

4. xorRoundKey()
Арк.
ЧДТУ.23.22187.002.ПЗ
2 2
Змн. Арк. № докум. Підпис Дата

На заключному етапі відбувається реалізується операція XOR між
отриманою таблицею та ключем.

2.2 Впровадження реєстрації та двофакторної автентифікації

Реєстрація це процес створення облікового запису користувача в системі.
Вона є першим кроком для взаємодії користувача з системою. Реєстрація
включає в себе надання основної інформації, такої як ім'я, логін та пароль.
Важливість правильної реєстрації полягає в тому, щоб забезпечити унікальність
облікових записів, а також забезпечити користувача засобами ідентифікації.
В розроблювальній системі для реєстрації слід обрати наступний перелік
даних:
1. Ім’я користувача – унікальне значення яке використовується для легшої
ідентифікації користувачів іншими користувачами. Не
використовується для ідентифікації користувача в системі;
2. Логін. В даній системі у вигляді логіну слід використати номер
телефону користувача. Логін є основними даними на основі яких
система ідентифікуватиме користувача при реєстрації та авторизації.
Використання номеру телефону обумовлено потребою виконання
двофакторної авторизації з підтвердженням по номеру;
3. Пароль – набір символів, цифр і букв який являє собою секретне слово
що використовується для запобігання несанкціонованому доступу до
системи.
Після введення всіх даних користувачем та відправкою їх на сервер
повинна відбуватися перевірка цих даних сервером. Сервер аналізує дані по
наступним критеріям:
• Відсутність введення імені;
• Відсутність логіну, не правильний формат що не співставний з номерним
форматом +380, наявність зареєстрованого користувача з таким же
логіном.

Арк.
ЧДТУ.23.22187.002.ПЗ
2 3
Змн. Арк. № докум. Підпис Дата

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

Рис 2.4 – Схема реєстрації користувача
Автентифікація - це процес перевірки ідентичності користувача перед тим,
як надати йому доступ до певних ресурсів або послуг. Основна мета
автентифікації полягає в тому, щоб забезпечити впевненість в тому, що особа яка
намагається отримати доступ, дійсно є тим, за кого себе видає.
Основні цілі автентифікації включають:
1. Захист від несанкціонованого доступу: Автентифікація допомагає
уникнути того, щоб невідомі або несанкціоновані користувачі отримували
доступ до конфіденційної інформації чи ресурсів;
2. Забезпечення конфіденційності: Автентифікація забезпечує, що тільки
власник облікового запису має право доступу до своїх особистих даних чи
інших конфіденційних інформаційних ресурсів;
3. Відстеження дій користувачів: Автентифікація дозволяє вести журнал дій
користувачів, що важливо для моніторингу та аудиту безпеки.
4. Забезпечення відповідності: В деяких випадках, особливо в регульованих
галузях, автентифікація є вимогою для відповідності законодавчим нормам
та стандартам безпеки.
Автентифікація в системі складатиметься з наступних етапів:
Арк.
ЧДТУ.23.22187.002.ПЗ
2 4
Змн. Арк. № докум. Підпис Дата

1. Введення та відправка даних користувачем;
2. Перевірка отриманих даних на відповідність очікуваному формату;
3. Перевірка бази даних користувачів на наявність зареєстрованого
облікового запису;
4. Перевірка відповідності надісланого паролю тому що вказувався при
реєстрації;
5. Генерація токену;
Також про розробці варто реалізувати функціонал що дозволяє відновити
пароль користувача після невдалого входження в систему через втрату свого
паролю. Система моніторить активність користувача і після трьох неправильних
введень паролю пропонує відновити пароль шляхом автентифікації через
надсилання коду на номер телефону.
Також важливо відзначити, що процес відновлення паролю після трьох
невдалих спроб входу є ефективним заходом безпеки для захисту від
несанкціонованого доступу. Після трьох неправильних спроб введення паролю
система сприймає це як потенційну атаку або спробу несанкціонованого доступу,
і вживає заходів для додаткової перевірки ідентичності користувача.

Рис 2.5 – Схема проходження автентифікації при входженні в систему

Арк.
ЧДТУ.23.22187.002.ПЗ
2 5
Змн. Арк. № докум. Підпис Дата

2.3 Використання токену для ідентифікації користувача

Токен – це безпечний та унікальний об'єкт, що використовується для
ідентифікації та автентифікації користувача в рамках клієнт-серверної
архітектури. Цей механізм використовується для передачі та підтвердження
ідентичності користувача під час обміну даними між клієнтом та сервером.
Роль токену в системі:
1. Ідентичність та автентифікація:
• Ідентифікація: Кожен користувач системи отримує унікальний
токен, що служить його цифровим відбитком. Цей токен ідентифікує
конкретну особу в системі;
• Автентифікація: Під час взаємодії з сервером користувач
представляє свій токен, який підтверджує його ідентичність. Це
забезпечує високий рівень безпеки, оскільки лише власник токена
може отримати доступ до системи;
2. Права та обмеження доступу:
• Токен містить інформацію про права доступу користувача.
Наприклад, рівень доступу може бути обмеженим до конкретних
ресурсів чи функцій системи. Це дозволяє точно визначати, які
операції користувач може виконувати;
3. Серверна авторизація:
• Після ідентифікації користувача токен використовується для
серверної авторизації. Сервер перевіряє валідність токену та
перевіряє, чи має користувач права доступу до запитаних ресурсів;
4. Шифрування та безпека даних:
• Інформація в токені зашифрована, забезпечуючи додатковий рівень
безпеки. Це може бути особливо важливим при передачі токенів
через незахищені мережі та підвищити рівень безпеки в захищених;
5. Управління сесією та часом дії:
Арк.
ЧДТУ.23.22187.002.ПЗ
2 6
Змн. Арк. № докум. Підпис Дата

• Токен має обмежений час дії, після закінчення якого він стає
недійсними. Це зменшує ризик використання вже неактивних
токенів та підвищує безпеку системи.
Переваги використання токену:
1. Безпека:
• Токен дозволяє ефективно захищати інформацію та ресурси системи
через свою унікальність та шифрування;
2. Гнучкість та управління доступом:
• Токен надає можливість ефективно визначати права доступу що
забезпечує гнучкість у конфігуруванні системи;
3. Валідність та журналювання:
• Система може валідувати та журналювати використання токенів що
допомагає виявити потенційні загрози та здійснювати контроль над
безпекою.
Для реалізації створення та перевірки токену в системі слід використати
JWT (JSON Web Token) - це стандарт токена доступу на основі JSON. Цей
стандарт описує компактні та автономні способи представлення інформації про
користувачів. Перевагами використання JWT є:
1. Легкість використання та розуміння:
• Формат JWT який базується на JSON легкий для читання та
розуміння. Це робить його зручним для використання у веб-
застосунках;
2. Самоконтейнерність:
• JWT містить в собі всю необхідну інформацію про користувача яка
була додана сервером на етапі генерування токену;
3. Криптостійкість:
• JWT підтримує використання сучасних стійких криптографічних
алгоритмів вибір яких можна здійснювати в залежності від
конкретних умов та вимог системи;

Арк.
ЧДТУ.23.22187.002.ПЗ
2 7
Змн. Арк. № докум. Підпис Дата

4. Розширюваність:
• JWT має ряд зарезервованих заявок, таких як «Iss» (видавець), «exp»
(час дії) та інші, що забезпечує високу функціональність та дозволяє
налаштувати токен під конкретну систему.

2.3.1 Принцип роботи токену, його генерація та перевірка
Для генерації JWT токену виконується наступна послідовність дій:
1. Визначення налаштувань токену та встановлення заголовків;
2. Додавання корисного навантаження;
3. Кодування заголовку та навантаження за допомогою Base64;
4. Створення цифрового підпису на основі заголовку та корисного
навантаження;
5. Формування тіла токену.
Перший етап генерації токену визначається при розробці системи.
Виконується дослідження системи, робочого середовище в якому вона буде
застосовуватися, конфігурації та взаємодії клієнтської сторони з сервером, на
основі чого визначаються налаштування токену які буду додані в заголовок.
Заголовок може містити наступні налаштування:
1. Alg – це поле вказує алгоритм який використовуватиметься для створення
цифрового підпису;
2. Typ – визначає тип токену, зазвичай має значення «JWT»;
3. Cty – вказує тип корисного навантаження;
4. Crit – вказує які заголовки слід розглядати як критичні при розробці;
5. Iat – час генерації токену;
6. Exp – час роботи токену.

Рис 2.6 – Приклад сформованого заголовку токену

Арк.
ЧДТУ.23.22187.002.ПЗ
2 8
Змн. Арк. № докум. Підпис Дата

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

Рис 2.7 – Приклад корисного навантаження токену

Після встановлення всіх потрібний налаштував та додавання даних про
користувача виконується кодування за допомогою Base64. Після кодування дані
приводяться до формату – заголовок (eyJhbGciOiAiSFMyNTYiL), крапка (.),
корисне навантаження (eyJzdWIiOiAiMTIzNDU2Nzg5MCIsICJuYW1lI).
Після цього отриманий рядок символів хешується та на його основі
створюється цифровий підпис який додається до токену після заголовку та
корисного навантаження. Алгоритми для хешування та створення підпису
визначаються у заголовках токену, наприклад HS256 що визначає алгоритм
HMAC для створення підпису та алгоритм SHA256 для створення хеш-функції.
Після проходження всіх етапів формування токен має наступний вигляд:

Рис 2.8 – Формат створеного токену

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

Арк.
ЧДТУ.23.22187.002.ПЗ
2 9
Змн. Арк. № докум. Підпис Дата

2.3.2 Вибір криптографічного алгоритму для хешування та створення
цифрового підпису
Обдуманий вибір криптографічних алгоритмів для хешування та
цифрового підпису є вкрай важливим елементом при роботі з токенами. Це не
лише забезпечує високий рівень захисту інформації, але й сприяє витрато-
ефективному використанню ресурсів.
Найчастіше при генерації JWT токену на етапі створення хеш-функції
використовують алгоритм SHA256.
SHA256 є алгоритмом сімейства SHA-2 та був розроблений Агентством
національної безпеки США. Робота алгоритму складається з п’яти етапів:
1. Ініціалізація початкових значень;
2. Підготовка вхідних даних:
• Доповнення вхідних даних до довжини що є кратної 256.
Доповнення включає в себе додавання одного біту «1» а далі «0» до
певної довжини;
3. Розбиття на блоки:
• Розділення доповнений вхідних даних на блоки по 256 біт (32 байти);
4. Ітерації і операції:
• Кожен блок проходить 32 ітерації обчислення;
• Кожна ітерація включає в себе велику кількість логічних та
арифметичних операцій такий як побітові операції, зсуви бітів, XOR;
5. Змішування та об’єднання:
• Результати кожної ітерації об’єднуються та змішуються, створюючи
нове значення;
• Оцінка кінцевого хеш-значення за всіма блоками вхідних даних.
Остаточний результат роботи алгоритму являє собою 256 – бітове хеш-
значення. Алгоритм SHA256 використовує ці етапи для обчислення хеш-функції
з високою стійкістю до колізій та інших атак.

Арк.
ЧДТУ.23.22187.002.ПЗ
3 0
Змн. Арк. № докум. Підпис Дата

Рис 2.9 – Схема однієї ітерації алгоритму

При виборі алгоритму для цифрового підпису вибір проводився між двома
найуживанішими алгоритмами в аспекті створення цифрового підпису токену,
HMAC та RSA.
HMAC (Hash-based Message Authentication Code) - це криптографічний
алгоритм, який використовує хеш-функцію для створення аутентифікаційного
коду для повідомлення. Основна мета HMAC - забезпечити автентичність та
цілісність даних.
Основні етапи алгоритму:
1. Визначення ключа:
• HMAC використовує секретний ключ для генерації
аутентифікованого коду.
2. Доповнення ключа:
• Якщо розмір ключа менший за розмір блоку хеш-функції, то ключ
доповнюється нулями справа;
3. Обчислення внутрішнього ключа для зовнішнього використання:
• Виконання операції XOR, кожен байт секретного ключа
об’єднується з константою 0х36;
4. Обчислення внутрішнього ключа для внутрішнього використання:
• Виконання операції XOR, кожен байт секретного ключа
об’єднується з константою 0х5С;

Арк.
ЧДТУ.23.22187.002.ПЗ
3 1
Змн. Арк. № докум. Підпис Дата

5. Обчислення хешу від об’єднання внутрішнього та зовнішнього ключів:
• Об’єднання внутрішнього та зовнішнього ключів;
• Використання хеш-функції (SHA256) для обчислення хеш-функції
від об’єднаних ключів та вхідного повідомлення.
6. Вивід результату:
• Результатом HMAC є хеш-функція яка використовується для
аутентифікації.
HMAC є стійким алгоритмом для багатьох застосувань, і його безпека
базується на властивостях використовуваної хеш-функції та правильній
реалізації алгоритму.
RSA – це асиметричний криптографічний алгоритм, який
використовується для шифрування та цифрового підпису.
Етапи роботи алгоритму:
1. Генерація ключів:
• Вибір двох великих простих чисел, скажімо, p та q.
• Обчислення їхнього добутку N = p * q. Значення N використовується
як модуль для обидвох ключів.
• Знаходження функції Ейлера (φ) для N, де φ(N) = (p-1)(q-1).
• Вибір відкритого ключа e (експонента), де 1 < e < φ(N) і e взаємно
просте з φ(N).
• Обчислення закритого ключа d, такого, що (e * d) % φ(N) = 1. Іншими
словами, d є мультиплікативним оберненим до e за модулем φ(N).
2. Шифрування:
• Користувач вибирає відкритий ключ (e, N) і шифрує повідомлення
M за допомогою математичного виразу: C ≡ M^e (mod N).С являється
зашифрованим повідомленням;
3. Дешифрування:
• Власник закритого ключа (d, N) розшифровує C, застосовуючи
математичний вираз: M ≡ C^d (mod N). Таким чином, отримується
початкове повідомлення M.
Арк.
ЧДТУ.23.22187.002.ПЗ
3 2
Змн. Арк. № докум. Підпис Дата

4. Цифровий підпис:
• Користувач підписує повідомлення M, зашифровуючи його своїм
закритим ключем, отримуючи C ≡ M^d (mod N).
• Інші користувачі можуть перевірити підпис, використовуючи
відкритий ключ (e, N): M' ≡ C^e (mod N). Якщо M' рівне M, то підпис
вважається дійсним.
Провівши дослідження цих алгоритмів зробив порівняльний аналіз для
визначення найбільш підходящого алгоритму для генерації JWT.

Таблиця 2.1 Порівняльний аналіз алгоритмів
Особливості HMAC RSA
Тип алгоритму Симетричний Асиметричний
Ключі Використовує секретний Використовує пару
ключ ключів (відкритий та
секретний)
Швидкість Зазвичай швидший та Зазвичай повільніший,
ефективніший особливо при обробці
великих обсягів даних
Ресурсомісткість Зазвичай використовує Зазвичай використовує
менший обсяг ресурсів більший обсяг ресурсів
через складнішу
структуру роботи
Ключі у JWT Єдиний ключ Використовує відкритий
використовується для ключ для перевірки
підпису та перевірки
Застосування в Добре підходить для Може
реальному часі JWT, особливо при використовуватися але
великих обсягах даних вимагає більшої
кількості ресурсів.

Арк.
ЧДТУ.23.22187.002.ПЗ
3 3
Змн. Арк. № докум. Підпис Дата

Загалом вибір між HMAC та RSA для генерації JWT токенів залежить від
конкретний потреб системи. Зважаючи на структуру, функціональність, та інші
системи забезпечення інформаційної безпеки серверу, вибір був зроблений на
користь HMAC. Вибір обумовлений кращою швидкодією та ресурсомісткістю
алгоритму. Також алгоритм забезпечує хорошу криптостійкість яка в основному
залежить від створення хеш-функції за допомогою SHA256. В свою чергу RSA
використовує значно більше ресурсів та часу, та є чутливим до генерації
початкових значень ключів.

2.3.3 Безпечна відправка та збереження токену
Питання безпеки при роботі з токенами є критично важливим для
забезпечення конфіденційності даних користувача. Загалом взаємодія клієнта та
сервера у роботі з токеном складається з трьох частин: відправка токену
сервером, збереження токену клієнтом, відправка токену клієнтом на сервер.
Найбільш вживаними способами відправки токену є:
1. Відправка токену в тілі відповіді;
2. Включення токену в заголовок відповіді;
3. Використання Cookie.
Відправка токену в тілі відповіді у вигляді JSON є одним із найпростіший
методів відправки токену. Після генерації токену він формується у JSON об’єкт
який містить сам токен, тип токену та час його дії.

Рис 2.10 – Структура JSON об’єкта для передачі токену
Сформований об’єкт передається в тілі відповіді клієнту. При отриманні
відповіді від сервера клієнтська сторона повинна отримати дані з тіла відповіді
та зберегти сам токен та дані про нього для подальшого відправлення на сервер.
Передача токену в тілі відповіді у вигляді JSON є безпечним способом у разі

Арк.
ЧДТУ.23.22187.002.ПЗ
3 4
Змн. Арк. № докум. Підпис Дата

Якщо тіло відповіді було зашифроване при передачі за допомогою безпечного
протоколу, такого як HTTPS.
Передача токену шляхом включення його в заголовок відповіді є
популярним методом у веб-розробці. Зазвичай, це використовується із
заголовком Authorization та схемою Bearer. Робота цього методу має наступну
структуру:
1. Створення токену на сервері:
• Аналогічно до попереднього методу, сервер генерує токен після
успішної аутентифікації користувача;
2. Включення токену в заголовок відповіді:
• Токен включається в заголовок відповіді, зазвичай в поле
Authorization за схемою Bearer. Токен може бути включений як
частина заголовка у відповіді на будь-який запит де потрібна
передача токену;

Рис 2.11 – Приклад передач токену в заголовку
3. Передача заголовка клієнту:
• Клієнт отримує токен, витягуючи його з заголовка відповіді після
чого зберігає для подальшого використання;
4. Безпека:
• Даний метод є безпечним при умові використання разом зі HTTPS.
Завдяки шифруванню, здійснюваному HTTPS токен залишається
конфіденційним під час передачі.
Вказання "Bearer" у схемі авторизації в заголовку Authorization є
стандартом, який визначений у RFC 6750 і використовується для передачі
токенів доступу в HTTP-запитах. Коли ви вказуєте "Bearer" в схемі, це сигналізує
про те, що вказане значення є токеном доступу (Bearer token).

Арк.
ЧДТУ.23.22187.002.ПЗ
3 5
Змн. Арк. № докум. Підпис Дата

Третім поширеним способом є передача токену в cookie. Передача токену
через куки є одним зі способів забезпечення безпеки та зручності при авторизації
та аутентифікації в веб-застосунках. Основний принцип полягає в тому, що
сервер включає токен в HTTPS-відповідь як куку, а клієнт автоматично включає
цю куку в заголовок кожного HTTPS-запиту.
Важливі аспекти передачі токену через cookie:
1. Створення та відправка Cookie на сервері:
• Після успішної аутентифікації та генерації токену, сервер включає
токен в cookie та відправляє їх в HTTPS відповіді.
• Set-Cookie: access_token=your_access_token; HttpOnly; Secure;
2. Зберігання cookie:
• Клієнт автоматично зберігає cookie та автоматично включає його в
кожен наступний запит на сервер. Після оновлення чи закриття
вкладки, браузер видаляє токен з cookie;
3. Безпека cookie:
• Використання cookie для збереження токенів може бути безпечним,
особливо якщо вони зашифровані та передаються через захищене
з'єднання HTTPS;
• Використання параметра HttpOnly допомагає захистити cookie від
атака пов’язаних з використанням Cross-Site Scripting (XSS), тому
що вона стає недоступною для скриптів на стороні клієнта;
• Встановлення параметра Secure гарантує що передача cookie буде
виконуватися лише через зашифроване з’єднання.
• Встановлення параметра SameSite дозволяє обмежити передачу
cookie між доменами.
Передача токену через cookie може бути зручною та ефективною, зокрема
при використанні веб-застосунків. Однак важливо дотримуватися загальних
принципів безпеки, таких як використання захищених з'єднань, встановлення
термінів дії токенів і включення додаткових заходів безпеки, щоб захистити дані
та користувачів.
Арк.
ЧДТУ.23.22187.002.ПЗ
3 6
Змн. Арк. № докум. Підпис Дата

Дослідивши популярні методи передачі токену створив порівняльну
таблицю для встановлення найкращого варіанту для використання в
розроблювальній системі.

Таблиця 2.2 Порівняльний аналіз методів передачі токену
Критерії JSON відповідь Передача в Cookie
заголовку
Ресурсоємкість Низька, легко Низька, легко Низька, легко
обробляється обробляється обробляється
сервером та сервером та сервером та
клієнтом клієнтом клієнтом
Поширеність Поширений, Поширений, Поширений у
часто стандартний веб-застосунках
використовується спосіб передачі
в API
Безпека токену Зашифрований Зашифрований Зашифрований
при передачі канал (HTTPS) канал (HTTPS) канал (HTTPS)
забезпечує забезпечує забезпечує
конфіденційність конфіденційність конфіденційність
Загальна безпека Потрібно дбати Стандартний Вимагає
про терміни дії метод, налаштування
токенів, обробку застосовується HttpOnly, Secure,
помилок та атаки разом з HTTPS та SameSite та
типу повторного іншими заходами вимогливий до
використання безпеки HTTPS
Зручність у Зручний для Зручний для API- Зручний для веб-
використання клієнтів, що запитів, застосунків,
обробляють стандартизований автоматично
JSON-відповіді у заголовку включається в
Authorization HTTP-запити
Арк.
ЧДТУ.23.22187.002.ПЗ
3 7
Змн. Арк. № докум. Підпис Дата

Відсутність даних Так Так Так
в URL

Провівши аналіз розроблювальної системи та виділених методів для
передачі токену, було обрано передачу даних в заголовку відповіді. Це
обумовлено тим що передача заголовка Authorization є стандартизованим
методом та використовується у багатьох протоколах. Це дозволяє легше
інтегрувати систему з іншими службами оскільки використання заголовка є
широко визнаним та прийнятим стандартом.
У порівнянні з включенням токену в тіло відповіді у форматі JSON,
передача в заголовку відповіді має менший обсяг даних та дозволяє уникнути
збереження токену в історії браузера та інших журналах як це може трапитися
при включенні в тіло відповіді.
Наступним кроком після генерації та відправки токену клієнту є безпечне
збереження токену для подальшого використанням. Враховуючи обраний метод
передачі токену було виділено два основі способи його збереження на клієнтські
стороні, це збереження в локальному сховище (Local Storage) та збереження в
сховищі Session Storage.
Збереження токену в локальному сховищі (Local Storage) є одним з
популярних методів на клієнтській стороні для роботи з токенами авторизації.
Локальне сховище забезпечує простий і зручний спосіб зберігання даних на боці
клієнта. Після отримання токену з заголовку відповіді виконується збереження
токену за допомогою методу setItem: localStorage.setItem('access_token', token);
Для безпеки використовується додавання унікального ключа щоб
вникнути конфліктів імен у локальному сховищі. Для отримання даних після
зберігання використовується функція getItem: const accessToken =
localStorage.getItem('access_token'); . При виході користувача з системи повинен
реалізовуватися метод для видалення токену зі сховища.
Даний метод є поширеним і достатньо комфортним у використанні проте
він вимагає створення окремих функцій для видалення токену після виходу

Арк.
ЧДТУ.23.22187.002.ПЗ
3 8
Змн. Арк. № докум. Підпис Дата

користувача із системи що ускладнює етап розробки системи.
Зберігання токену в session Storage подібне до збереження в local Storage,
але session Storage має специфічні особливості, які роблять його більш
підходящим для застосування в даній системі. Session Storage зберігає дані тільки
на час життя сесії браузера, тобто доки вікно або вкладка браузера залишається
відкритим. Коли користувач закриває вкладку чи вікно браузера, дані в session
Storage видаляються.
Збереження токену після отримання його із заголовку подібне до
попереднього методу, в цьому випадку також використовується метод setItem
однак для sessionStorage: sessionStorage.setItem(‘access_token’, token);
Для отримання токену з sessionStorage використовується наступний код:
const accessToken = sessionStorage.getItem('access_token');
SessionStorage не є підходящим для довготривалого зберігання даних але
добре підходить для тимчасового зберігання завдяки автоматичному видаленню
даних при закритті вкладки чи перезапуску браузера. Це дозволить оптимізувати
код та полегшити розробку системи.

2.3.4 Перевірка токену сервером
Заключним етапом роботи із токеном є його перевірка сервером при
отриманні запиту від користувача. Робота з токеном при отриманні запиту
складається з наступних частин:
1. Перенаправлення запитів в яких очікується передавання токену:
• При розробці клієнт-серверної системи визначаються структура
запитів до сервера та їх розподілення за типом доступу. Виділяється
ряд запитів які повинні містити в собі токен для автентифікації
користувача;
• Методи що відповідають за початкову обробку запитів
налаштовуються таким чином щоб вони перенаправляли визначений
перелік запитів на функції перевірки токену. Наприклад запити
пов’язані з реєструванням чи проходженням автентифікації
Арк.
ЧДТУ.23.22187.002.ПЗ
3 9
Змн. Арк. № докум. Підпис Дата

пропускаються, а запити які стосуються роботи з даними для
конкретного користувача перенаправляються на перевірку;

Рис 2.12 – Схема перенаправлення запитів

2. Перевірка запитів на вміст токену, та їх верифікація:
• Надісланий запит перевіряється на вміст токену в заголовку
«Authorization»;
• При наявності токену виконується його перевірка засобами JWT.
При використанні алгоритму HS256 перевірка виконується шляхом
створення хеш-функції на основі даних токену, а саме заголовку та
корисного навантаження, та співставленні отриманої хеш-функції з
хеш-функцією що була передана токеном у розділі «Signature»;
• Якщо токен був відсутній у заголовку «Authorization» або створена
хеш-функція відмінна від переданої у розділі «Signature», сервер
розпізнає користувача як не аутентифікованого, зупиняє будь-які
подальші дії із запитом, та надсилає користувачу дані про помилку;
• Якщо токен містився у заголовку та він успішно пройшов перевірку,
сервер витягує з тіла токену корисне навантаження, додає його до
тіла запиту та передає запит далі.
Отже, загальна робота з токеном виглядає наступним чином:
1. Автентифікація користувача в системі;
2. Генерація та безпечна відправка токену користувачу;
3. Отримання токену та безпечне зберігання на клієнтські стороні;
Арк.
ЧДТУ.23.22187.002.ПЗ
4 0
Змн. Арк. № докум. Підпис Дата

4. Додавання токену в заголовок «Authorization» при створенні запитів на
сервер;
5. Перевірка запиту на вміст токену, та його верифікація.
6. Перенаправлення запиту на подальші методи.

Рис 2.13 – Схема загального циклу роботи з токеном

2.4 Впровадження заходів спрямованих на захист від ін’єкцій

SQL ін'єкція є однією з найрозповсюдженіших атак на бази даних, і
відсутність належних захисних заходів може призвести до серйозних наслідків
для безпеки та функціональності системи. Захист серверу від SQL ін'єкцій є
невід'ємною та надзвичайно важливою частиною будь-якої клієнт-серверної
системи. Це завдання особливо вирізняється, оскільки SQL ін’єкції можуть
викликати серйозні наслідки для стійкості, конфіденційності та доступності баз
даних.
Ризики та наслідки SQL ін’єкцій:
1. Втрата конфіденційності:
Атака ін'єкції може призвести до неправомірного доступу до чутливих
даних, таких як паролі, особисті ідентифікаційні дані чи інша інформація;
2. Втрата цілісності даних:

Арк.
ЧДТУ.23.22187.002.ПЗ
4 1
Змн. Арк. № докум. Підпис Дата

Атаки ін'єкцій можуть викликати некоректне внесення змін у базу даних,
порушуючи цілісність інформації та можливо ведучи до втрати даних;
3. Втрата доступу:
Неконтрольовані атаки можуть призвести до блокування доступу до бази
даних, обмежуючи функціональність системи.
Важливість захисту:
1. Попередження атак:
Впровадження механізмів, які фільтрують та валідують вхідні дані, є
вирішальним для попередження можливих атак ін'єкцій SQL;
2. Збереження функціональності:
Захист від ін'єкцій забезпечує правильне функціонування системи,
уникаючи непередбачених змін у виконанні запитів до бази даних.
3. Довіра користувачів:
Відповідний захист від ін'єкцій підвищує рівень довіри користувачів,
оскільки їх конфіденційні дані залишаються в безпеці.
Загально кажучи, належний захист від ін'єкцій SQL є критично важливим
для забезпечення стійкості та надійності клієнт-серверних систем, а також для
збереження довіри користувачів до надання конфіденційної інформації.
При розробці захищеної клієнт-серверної системи потрібно впровадити
два основних заходи що до захисту від ін’єкцій:
1. Перевірка введених даних:
• Перевірка даних перед їх використанням у SQL запитах що запобігає
некоректним вхідним даних;
• Створення спеціалізованих функцій перевірки отриманих запитів та
розробка стійкої структури системи що унеможливить обхід
перевірки;
2. Параметризовані запити:
• Використання параметризованих запитів усуває можливість
впровадження шкідливого коду через введені дані.

Арк.
ЧДТУ.23.22187.002.ПЗ
4 2
Змн. Арк. № докум. Підпис Дата

2.4.1 Робота з базою даних
Використання бази даних є основою для реалізації клієнт-серверної
системи. Використання бази даних дозволяє забезпечити виконання ряду
функцій:
1. Зберігання та організація даних:
Бази даних дозволяють ефективно зберігати та організовувати великі
обсяги даних. Це допомагає підтримувати структурований та легко доступний
набір інформації для обробки як на стороні клієнта, так і на стороні сервера;
2. Швидкий та ефективний доступ:
Використання баз даних дозволяє використовувати різноманітні техніки
індексації та оптимізації запитів, щоб забезпечити швидкий та ефективний
доступ до інформації. Це особливо важливо при опрацюванні запитів великої
кількості користувачів;
3. Безпека та контроль доступу:
Бази даних забезпечують механізми для контролю доступу до інформації.
Це означає, що можна визначити, які користувачі чи ролі мають доступ до
конкретних частин даних, забезпечуючи таким чином безпеку і
конфіденційність;
4. Зручність у виконанні запитів та звітності:
Бази даних дозволяють легко виконувати складні запити та створювати
звіти, спрощуючи аналіз інформації. Це полегшує прийняття рішень на основі
даних і вдосконалює роботу з інформацією;
5. Масштабованість та зручність роботи з даними:
З використанням баз даних легше реалізувати масштабовані та розподілені
системи, так як вони дозволяють ефективно працювати з великими обсягами
даних.
При розробці клієнт-серверної системи для роботи з базою даних обрано
СУБД PostgreSQL. PostgreSQL – це об’єктно-реляційна система управління
базами даних яка має широке використання у веб-додатках. Вона забезпечує весь
функціонал потрібний при розробці даної системи.

Арк.
ЧДТУ.23.22187.002.ПЗ
4 3
Змн. Арк. № докум. Підпис Дата

Ключові аспекти та характеристики PostgreSQL:
1. Властивості та стандарти:
PostgreSQL дотримується стандартів SQL і підтримує багато функцій, які
можуть бути знайдені в інших комерційних та відкритих СУБД. Також реалізує
деякі продвинуті функції, які його вирізняють;
2. Об’єктно-реляційна модель:
PostgreSQL підтримує об'єктно-реляційну модель даних, що дозволяє
працювати як з традиційними реляційними даними, так і з об'єктами, такими як
класи, успадкування та методи;
3. Розширені типи даних:
В PostgreSQL є розширений набір типів даних, включаючи JSON, XML, і
багато інших. Це дозволяє більш гнучко виражати та зберігати різноманітні дані;
4. Транзакції та запити:
PostgreSQL підтримує транзакційну модель даних, що дозволяє
виконувати групу операцій як одну атомарну операцію. Він також має потужний
оптимізатор запитів;
5. Розширюваність та гнучкість:
PostgreSQL дозволяє створювати власні функції та типи даних, що робить
його дуже гнучкою та розширюваною для різних сценаріїв використання;
6. Велика спільнота та підтримка:
Є широка спільнота користувачів та розробників, яка надає підтримку та
розвиває систему. Крім того, PostgreSQL має активний форум, список розсилки
та інші ресурси для обговорення та отримання допомоги;
PostgreSQL є потужною та надійною СУБД, яка забезпечує високий рівень
функціональності для розробників.
Що до звернення до PostgreSQL в коді сервера то для цього
використовується pg-pool.
Pg-pool або PostgreSQL Connection Pool – це інструмент для керування
підключенням до бази даних PostgreSQL у веб-додатках та інших середовищах
де важливо ефективно використовувати та керувати ресурсами підключення.

Арк.
ЧДТУ.23.22187.002.ПЗ
4 4
Змн. Арк. № докум. Підпис Дата

Основні риси та можливості pg-pool.
1. Пул підключень:
Рg-pool управляє пулом підключень до бази даних. Замість того, щоб
кожен клієнт відкривав та закривав своє власне підключення, pg-pool створює
пул активних підключень, які можуть використовуватися та
перевикористовуватися різними клієнтами;
2. Моніторинг та керування запитами:
Рg-pool надає можливості моніторингу та керування запитаннями до бази
даних. Він може аналізувати та втручатися в запити для їх оптимізації;
3. Множинне використання підключень:
Рg-pool дозволяє групувати підключення та використовувати їх в
множинних режимах, що дозволяє реалізувати різні стратегії роботи з
підключеннями в залежності від потреб додатка;
Робота з підключенням складається з трьох частин:
1. Імпортування бібліотеки pg;
2. Створення нового екземпляру pool із заданими параметрами:
• «user» - ім’я користувача бази даних, в моєму випадку стандартне
ім’я postgres;
• «password» - пароль користувача бази даних;
• «host» - адреса бази даних, у моєму випадку база даних зберігається
локально;
• «port» - порт на якому працює сервер бази даних;
• «database» - назва бази даних до якої виконується доступ;
• «encoding» - кодування бази даних;
3. Експортування екземпляру pool для створення запитів до бази даних в
інших функціях.
Після забезпечення підключення до бази даних вся подальша робота з pg-
pool зводиться до створення та відправки SQL запитів. Pg-pool дозволяє
створювати два типи запитів, не параметризований та параметризований.
Перший тип запиту реалізується шляхом окремого створення SQL запиту,
Арк.
ЧДТУ.23.22187.002.ПЗ
4 5
Змн. Арк. № докум. Підпис Дата

при якому додавання переданих клієнтом даних виконується шляхом
конкатинації та утворення єдиного рядка SQL коду. Після чого створений запит
передається до бази даних за допомогою pg-pool.

Рис 2.14 – Створення запиту шляхом конкатинації
При такому типі утворення запиту система стає вразливою до виникнення
SQL ін’єкцій. При утворенні такого запиту потрібно впевнитись що попередній
етап перевірки даних отриманих від користувача був пройдений успішно, та дані
що додаються до запиту не несуть загрози базі даних.
Для більш безпечної роботи з базою даних потрібно використовувати
другий метод, параметризовані запити. Цей метод доцільно використовувати у
тому разі коли перевірка даних надісланих користувачем не виконується або її
виконання є ускладненим, наприклад при надсиланні користувачем тексту,
системі буде важко розпізнати де простий текст а де SQL код який може бути
використаний для ін’єкцій.
Структура параметризованого запиту складається з наступних частин:
1. «pool.query» - метод що дозволяє виконувати запити до бази даних через
пул підключень;
2. Визначення загальної структури SQL запити в залежності до потреб (у
даному випадку додавання даних «insert into»);
3. Встановлення індикаторів «$» у місцях додавання параметрів;
4. «returning * » - після вставки нового рядка в базу даних ця частина повертає
всі стовпці нового рядка. Це дозволяє отримати значення, які були додані;
5. Визначення даних які будуть додані в SQL запит. Вказані значення
додаються в запит відповідно до порядкових номерів.

Рис 2.15 – Структура параметризованого запиту
Арк.
ЧДТУ.23.22187.002.ПЗ
4 6
Змн. Арк. № докум. Підпис Дата

Після створення запиту pg-pool перевіряє його, та у разі якщо запит
викликає помилку, чи структура запиту є не типовою та може містити подвійне
використання взаємовиключних SQL операторів, він не буде виконаний.

2.4.2 Перевірка отриманий файлів
Перевірка файлів, які надсилаються на сервер від користувачів, є
критичним елементом забезпечення безпеки у веб-додатках. Неправильно
реалізована або відсутня перевірка може вести до серйозних проблем безпеки та
вразливостей, які можуть використовуватися для атак та зловживань. Ось деякі
наслідки цих проблем:
1. Виконання коду:
Якщо сервер дозволяє завантаження файлів без належної перевірки, це
може призвести до виконання впровадженого коду, який міститься у
завантажених файлах. Це велика загроза для безпеки, оскільки зловмисник може
використовувати це для виконання шкідливого коду на сервері;
2. Ін’єкції та компрометація даних:
Зловмисник може завантажити файл із шкідливим кодом, який
впроваджує ін'єкції в базу даних чи інші системні компоненти. Це може вести до
витоку чутливих даних чи їх пошкодженню;
3. Відмова у обслуговуванні:
Завантаження великої кількості великих файлів може викликати
перевантаження сервера, призводячи до відмови у обслуговуванні для інших
користувачів. Це може бути частиною DDoS атаки;
4. Збої в роботі системи:
Неправильна перевірка файлів може дозволити атакуючим введення
шкідливих файлів, які обмежують системні перевірки. Це може викликати
різноманітні збої та непередбачувану поведінку системи;
5. Розголошення системної інформації:
Якщо файли не перевіряються на вміст, це може призвести до витоку такої
інформації як паролі, ключі доступу.
Арк.
ЧДТУ.23.22187.002.ПЗ
4 7
Змн. Арк. № докум. Підпис Дата

Дослідивши структуру розроблювальної системи, її функціонал, та наявні
системи для перевірки файлів на шкідливе програмне забезпечення мною було
обрано впровадження перевірки файлів за допомогою ClamAV.
ClamAV (Clam AntiVirus) – це відкрита антивірусна система, яка
спроектована для виявлення шкідливого програмного забезпечення. Дана
система має ряд переваг які виділили її на фоні інших систем:
1. Безкоштовність:
ClamAV є безкоштовним для використання. Це робить його доступним для
широкого кола розробників;
2. Кросплатформенність:
ClamAV підтримує різні операційні системи що робить його
універсальним для застосуванням в різних середовищах;
3. Регулярні оновлення бази даних вірусів:
ClamAV активно оновлює свої бази даних вірусів що дозволяє виявляти
актуальні віруси та загрози безпеці;
4. Підтримка визначень підписів та поведінки:
ClamAV використовує як визначення підписів, так і методи поведінкової
детекції для виявлення шкідливих програм;
5. Низькі вимоги до ресурсів:
ClamAV відомий своєю ефективністю та низькими вимогами до ресурсів.
Це робить його придатним для використання на серверах та системах з
обмеженими ресурсами;
6. Антивірусна оцінка:
ClamAV дає можливість очищення інфікованих файлів;
7. Гнучкість у використанні:
ClamAV можна легко інтегрувати в різні середовища в тому числі і
сервери.

Арк.
ЧДТУ.23.22187.002.ПЗ
4 8
Змн. Арк. № докум. Підпис Дата

2.5 Моніторинг та журналювання

Моніторинг та журналювання запитів, які отримує сервер є ключовим
аспектом управління інформаційної системою. Впровадження цих систем
дозволяє забезпечити виконання наступних завдань:
1. Виявлення проблем:
• Моніторинг і журналювання допомагають вчасно виявляти та
вирішувати проблеми з продуктивністю, які можуть виникнути в
роботі сервера;
• Запис подій у журналі дозволяє адміністраторам та розробникам
швидко здогадатися про можливі неполадки;
2. Безпека:
• Аналіз логів допомагає виявляти спроби несанкціонованого доступу,
атаки або інші потенційні загрози безпеці;
• Відстеження та аналіз запитів може допомогти у виявленні паттернів
та вразливостей, що можуть бути використані зловмисниками;
3. Оптимізація продуктивності:
• Моніторинг навантаження сервера та аналіз логів можуть допомогти
в оптимізації продуктивності за рахунок виявлення слабких місць та
ефективного використання ресурсів;
4. Аналіз взаємодії:
• Відслідковування взаємодії між різними компонентами системи
дозволить забезпечити стабільну роботу всього середовища;
5. Відновлення після взаємодії:
• Логи можуть бути використані для аналізу причин системних збоїв і
відновлення системи в якнайкоротший термін;
6. Відповідь на інциденти:
• Моніторинг і журналювання дозволяють виявляти інциденти та
надавати швидку відповідь на них, зменшуючи час відновлення
системи;
Арк.
ЧДТУ.23.22187.002.ПЗ
4 9
Змн. Арк. № докум. Підпис Дата

7. Відстеження використаних ресурсів:
• Запити і дані, записані в журналах, можуть допомогти в аналізі
використання ресурсів, таких як пам'ять, процесор та мережеві
ресурси.
Загалом, моніторинг та журналювання запитів створюють засіб для аналізу
та вдосконалення роботи сервера, забезпечуючи ефективність, безпеку та
надійність інформаційної системи.
Для впровадження моніторингу та журналювання слід застосувати дві
системи: Winston та Morgan.
Winston – це бібліотека для логування в середовищі Node.js. Основна мета
Winston забезпечити ефективні інструменти для обробки і запису різноманітної
інформації, яку можна використовувати для моніторингу та аналізу додатка.
Основні функції Winston:
1. Логування подій:
• Winston дозволяє легко логувати події різних рівнів, такі як
інформаційні повідомлення, попередження, помилки;
2. Налаштування збереження:
• Winston підтримує різні шляхи збереження логів, наприклад
виведення їх в консоль, збереження у файл, відправка для хмарного
зберігання, збереження у базу даних;
3. Структурування:
• Winston дозволяє логувати структуровані дані, такі як об’єкти чи
JSON, що полегшує аналіз логів;
4. Налаштування рівнів логування:
• Winston дозволяє налаштовувати рівні логів і фільтрувати їх в
залежності від потреби;
5. Формування логів:
• Winston дозволяє налаштовувати формат виведення логів;
Morgan – це middleware для логування HTTP запитів в Node.js додатках.
Він реалізований як middleware для фреймворків веб-додатків таких як express.
Арк.
ЧДТУ.23.22187.002.ПЗ
5 0
Змн. Арк. № докум. Підпис Дата

Morgan генерує записи журналу що містять інформацію про HTTP – запити і
дозволяє легко відстежувати та аналізувати цю інформацію.
Основні функції Morgan:
1. Логування HTTP запитів:
• Morgan створює логи для кожного HTTP – запиту реєструючи різні
аспекти запиту, такі як метод URL, код стану, розмір відповіді та
інші параметри;
2. Форматування логів:
• Morgan дозволяє вибрати різні формати для виведення догів;
3. Власні формати логів:
• При розробці можливе налаштування власних форматів виведення
логів шляхом створення шаблонів;
4. Підтримка middleware:
• Morgan може легко використовуватися разом із іншими middleware і
додавати можливості логування в будь-які частині системи;
Приклад виконання функцій логування. Сервер отримує запит, отримує
інформацію про нього за допомогою Morgan та передає її на Winston. В свою
чергу Winston реагує та зберігає дані про помилку при обробці запиту.

Рис 2.16 – Структура логування запиту користувача та помилки

Арк.
ЧДТУ.23.22187.002.ПЗ
5 1
Змн. Арк. № докум. Підпис Дата

2.6 Структура системи

Створення продуманої та безпечної структури клієнт-серверної системи
для передачі даних важливе з численних причин:
1. Масштабованість:
• Проектування системи з урахуванням потенційного зростання
обсягу даних та кількості користувачів;
• Використання технологій що дозволяють гнучко масштабувати
систему;
2. Ефективність:
• Використання оптимізованих алгоритмів та структур даних для
швидкої обробки і передачі інформації;
3. Стандартизація:
• Дотримання стандартів протоколів та інтерфейсів для сумісності з
різними платформами та системами;
4. Моніторинг та аудит:
• Забезпечення можливості ведення журналів та аудиту дій для
виявлення ненормативних ситуацій та аналізу подій;
5. Керованість:
• Розробка інтерфейсів для адміністрування та моніторингу систем;
• Створення розгалудженої структури яка чітко розділяє всі ролі у
роботі системи, що полегшує розуміння системи, моніторинг, та
впровадження нового функціоналу;
6. Надійність:
• Створення надійних підсистем та продуманої структури яка не
дозволить зловмисникам обійти впроваджені системи захисту та
журналювання;
7. Документація:
• Створення докладної документації для розуміння структури.

Арк.
ЧДТУ.23.22187.002.ПЗ
5 2
Змн. Арк. № докум. Підпис Дата

Розроблювана система повинна складатися з двох загальних частин:
клієнтської частини що слугує для відображення даних, отримання даних від
користувача та відправки їх на сервер, та серверної частини яка приймає запити
від користувача та відповідає на них.
Клієнтська частина являє собою додаток розроблений з використанням
відкритої JavaScript бібліотеки React. Він повинен бути розділений на наступні
складові:
1. Головний файл:
• Головний файл додатку який об’єднує в собі роботу інших
компонентів та відповідає за їх відображення користувачу;
2. Головні компоненти:
• Компонент «auth/reg» що відповідає за взаємодію користувача з
сервером при його реєстрації та автентифікації. Створює весь
потрібний для цього інтерфейс. Приймає в себе підкомпоненти
«authentication» та «registration»;
• Компонент «home». Відповідає за відображення всього інтерфейсу
домашньої сторінки користувача. Приймає в себе підкомпоненти
«chal» та «message», що відповідають за роботу зі списком чату та
відправкою повідомлень;
3. Підкомпоненти:
• Компонент «authentication», реалізує відображення інтерфейсу для
автентифікації користувача. Перенаправляє введені користувачем
дані на виконавчі функції для автентифікації;
• Компонент «registration», реалізує відображення інтерфейсу для
реєстрації користувача. Перенаправляє введені користувачем дані на
виконавці функції для реєстрації;
• Компонент «chat», реалізує відображення інтерфейсу для роботи
користувача з чатами. Створення нового чату та перехід до вже
існуючого. Перенаправляє команди та дані користувача на виконавчі
функції;
Арк.
ЧДТУ.23.22187.002.ПЗ
5 3
Змн. Арк. № докум. Підпис Дата

• Компонент «message», реалізує відображення інтерфейсу для
надсилання та перегляду повідомлень. Відповідає за відображення
надісланих повідомлень та отримання від користувача даних таких
як текст повідомлень або файли;
4. Виконавчі функції:
• Функції роботи з реєстрацією та автентифікацією. Відповідають за
обробку даних введених користувачами, формування та надсилання
запитів на сервер, отримання даних від сервера та їх відображення у
підкомпонентах;
• Функції роботи користувача на домашні сторінці. Відповідають за
обробку даних та команд отриманих від користувача. Надсилають
запити на сервер, та відображають користувачу дані отримані з
сервера, наприклад: список чатів, текст переписки, збережені файли.
Серверна сторона являє собою розроблений за допомогою платформи
Node.js сервер, який обробляє запити користувача. Саме тут реалізується весь
функціонал роботи з даними та забезпечення безпеки системи.
Сервер складається з наступних частин:
1. Головний маршрутизатор:
• Програмно реалізований маршрутизатор який отримує запити від
користувача, аналізує їх, і на основі вказаної в запиті URL адреси
передає запит на два інші маршрутизатори;
2. Middleware:
• Проміжне програмне забезпечення. В даній системі виконуватиме
функції перевірки токену та журналювання отриманих запитів;
3. Маршрутизатори нижчого рівня:
• Маршрутизатор для роботи з реєстрацією та автентифікацією
користувачів. Виконує аналіз URL адреси запиту та передає його на
потрібні методи контролера що з ним взаємодіє;
• Маршрутизатор для обробки запитів з домашньої сторінки веб-
додатку. Виконує аналіз URL адреси та передає його на потрібні
Арк.
ЧДТУ.23.22187.002.ПЗ
5 4
Змн. Арк. № докум. Підпис Дата

методи контролера що з ним взаємодіє. Наприклад методи для
створення нового чату чи надсилання повідомлення;
4. Контролери:
• Допоміжне програмне забезпечення що слугує з’єднанням між
маршрутизатором та функціями обробки запитів. Слугує для кращої
структуризації системи та полегшення додавання нових функцій;
5. Виконавчі функції:
• Функції для роботи з реєстраціє та автентифікацією користувача.
Виконують основну роботу з запитом: отримання даних з тіла
запиту, їх перевірка на вміст шкідливих елементів, формування та
відправка запиту до бази даних, відправка відповіді користувачеві;
• Функції для роботи із запитами з домашньої сторінки користувача.
Реалізують обробку запиту, перевірку надісланих даних, перевірку
файлів, створюють на надсилають запити до бази даних. Формують
та відправляють відповіді користувачу.

Висновки до розділу 2

В даному розділі детально розглянуті ключові заходи забезпечення
інформаційної безпеки що слід впровадити в розроблювані клієнт-серверні
системі.
В роботі висвітлено реалізацію захищеного з’єднання між клієнтом та
сервером за допомогою протоколу HTTPS. Розглянуто всі етапи формування
зашифрованого з’єднання між клієнтом та сервером.
Описано впровадження двофакторної автентифікації, та процес реєстрації
нових клієнтів. Розглянуто роботу сервера з вхідними даними клієнта що
слугують для його автентифікації в системі.
Висвітлено використання JWT токенів для ідентифікації користувачів.
Детально розглянуто етапи формування токену, його відправки клієнту, та
безпечного зберігання токену клієнтом. Досліджено алгоритми хешування для

Арк.
ЧДТУ.23.22187.002.ПЗ
5 5
Змн. Арк. № докум. Підпис Дата

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

Арк.
ЧДТУ.23.22187.002.ПЗ
5 6
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 3

РЕАЛІЗАЦІЯ ЗАХИЩЕНОЇ СИСТЕМИ ОБМІНУ ДАНИМИ НА ОСНОВІ
КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ. ТЕСТУВАННЯ СИСТЕМИ

3.1 Створення захищеного з’єднання клієнта і сервера

Для розробки серверу працюючому на протоколі HTTPS було обрано
середовище розробки для JavaScript Node.js. Воно дозволяє виконувати
JavaScript код на сервері, надає можливості створювати високопродуктивні,
масштабовані застосунки. Має асинхронну модель виведення/введення що
важливо для роботи серверу та реалізації зв’язку з базою даних. Має широкий
вибір доступних бібліотек і рішень для розробки серверів.
Сертифікат та ключ для серверу згенеровано за допомогою OpenSSL.
OpenSSL це відкрите ПЗ яке реалізує імплементацію протоколів SSL і TLS.
Також включає створення SSL – сертифікатів. Для розробки даної системи мною
було згенеровано самопідписний сертифікат.
Генерація ключа відбувається за допомогою наступного коду: openssl
genpkey -algorithm RSA -out key.pem.
Генерація сертифікату відбувається на основі ключа та з параметрами які
вказують на термін дії сертифікату та його тип: openssl req -new -key key.pem -
x509 -days 365 -out certificate.pem.
Програмна реалізація запуску сервера виглядає наступним чином.

Рис 3.1 – Запуск локального серверу
Арк.
ЧДТУ.23.22187.002.ПЗ
5 7
Змн. Арк. № докум. Підпис Дата

Для запуску серверу було застосовано модуль https який дає додатковий
шар безпеки з’єднання та має функції роботи з SSL/TLS.
Після запуску сервер та надсилання запиту від користувача виконується
автоматичне налаштування параметрів шифрування.

3.2 Створення функціоналу для реєстрації та двофакторної
автентифікації користувача

Створення функціоналу для впровадження реєстрація та двофакторної
автентифікації складається з двох частин:
1. Створення компонентів та функцій клієнтського додатку, що забезпечать
користувача потрібним функціоналом та реалізують відправку отриманих
даних на сервер;
2. Створення функціоналу з обробки надісланих даних, підтвердження
ідентичності користувача та збереження даних про нього в базу даних.
Інтерфейс клієнтського додатка для проходження реєстрації виглядає
наступним чином:

Рис 3.2 – Інтерфейс користувача для проходження реєстрації
Він містить поле для введення імені користувача, поле для введення
номеру телефону, поле для введення паролю. Відображення даного інтерфейсу
відбувається шляхом рендеру головного компонента «auth/reg» та підкомпонента
«registration», які мають в собі html код який створює потрібні елементи та
містить посилання на програмні функції для обробки подій, таких як введення
Арк.
ЧДТУ.23.22187.002.ПЗ
5 8
Змн. Арк. № докум. Підпис Дата

користувачем інформації, натискання на кнопку «Зареєструватися».
Після отримання даних від користувача клієнтський додаток обробляє їх,
та передає у функції відправки запиту на сервер.

Рис 3.3 – Запит на проведення реєстрації користувача

Сервер отримує запит та проводить перевірку отриманих даних. Якщо всі
потрібні дані введені, та знаходяться в коректному форматі, сервер запускає
процес двофакторної автентифікації.
Для реалізації функціоналу з надсилання коду для підтвердження
користувача було застосовано платформу Twilio. Це хмарна платформа яка надає
функціонал взаємодії з телефоном та текстовими повідомлення. Відправка
повідомлення виконується через зареєстрований обліковий запис, доступ до
якого виконується в коді через ідентифікатори Account SID та Auth token.
Після відправки коду на номер телефону, користувач повинен надіслати
код на сервер для перевірки. Якщо код збігається з надісланим, сервер виконує
збереження даних користувача в базі даних та присвоює йому унікальний
ідентифікатор в системі. Після чого відбувається перенаправлення користувача
на сторінку з автентифікацією.

Рис 3.4 – Інтерфейс користувача для проходження автентифікації

Арк.
ЧДТУ.23.22187.002.ПЗ
5 9
Змн. Арк. № докум. Підпис Дата

Робота клієнтського додатка при реєстрації складається з двох частин:
отримання даних від користувача, відправка даних користувача на сервер.
Відображення інтерфейсу для проходження автентифікації відбувається шляхом
рендеру головного компонента «auth/reg» та підкомпонента «authentication».
Вони дозволяють користувачу ввести свої дані, після чого передають їх на
функції для надсилання запиту.

Рис 3.5 – Запит на проведення автентифікації користувача

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

3.3 Генерація, відправка, збереження та перевірка токену

Робота системи з токеном складається з наступних частин:
1. Генерація токену на сервері;
2. Відправка токену користувачу;
3. Безпечне збереження токену користувачем;
4. Відправка токену на сервер;
5. Перевірка токену на сервер.
Генерація токену на сервері реалізована за допомогою JWT (JSON Web
Token) та проходить у кілька етапів:
1. Запит до бази даних та отримання інформації про користувача:
Арк.
ЧДТУ.23.22187.002.ПЗ
6 0
Змн. Арк. № докум. Підпис Дата

Відповідно до даних які користувач ввів при автентифікації, сервер
виконує запит до бази даних та отримує унікальний ідентифікатор користувача,
та його логін, які в подальшому будуть використовуватися для надання
користувачеві доступу до даних на сервері та реалізації передачі даних між двома
користувачами;
2. Встановлення заголовків відповідно до проведених досліджень:
На цьому етапі програмно формував та налаштував заголовки для токену.
Відповідно до проведеного дослідження, для створення токену застосовується
алгоритм HS256.
3. Створення корисного навантаження:
На цьому етапі відповідно до даних отриманих із бази даних, формується
корисне навантаження.
4. Створення цифрового підпису на основі заголовку та корисного
навантаження.

Рис 3.6 – Генерація токену.

Після збереження токену відбувається його відправка. Відправка токену
клієнту, та в подальшому відправка токену від клієнта на сервер відбувається
подібним чином, шляхом передачі токену в заголовку «Authorization». Таке
передавання є стандартизованим та дозволяє сигналізувати системі про те що
запит містить в собі токен.

Рис 3.7 – Приклад відправки токену в заголовку «Authorization»
Арк.
ЧДТУ.23.22187.002.ПЗ
6 1
Змн. Арк. № докум. Підпис Дата

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

Рис 3.8 – Перевірка токену користувача

3.4 Реалізація систем захисту від ін’єкцій. Перевірка надісланих
файлів

Захист системи від ін’єкцій складається з наступних частин:
1. Перевірка введених даних;
2. Створення параметризованих запитів до бази даних;
3. Перевірка файлів на вміст шкідливого програмного забезпечення.
Для реалізації перевірки даних надісланих користувачем було
впроваджено в роботу функції які отримують запит, перевіряють його, та після
перевірки відправляють його на подальші функції.
Етапи роботи функцій перевірки:

Арк.
ЧДТУ.23.22187.002.ПЗ
6 2
Змн. Арк. № докум. Підпис Дата

1. Отримання запиту від користувача:
• Сервер отримує запит, обробляє URL адресу цього запиту, та у
відповідності до нього перенаправляє запит на інші функції;
2. Обробка запиту та отримання з нього інформації:
• Обробка URL запиту та отримання даних з нього, якщо функціонал
даного запиту передбачає такий метод передачі даних;
• Деструктуризація тіла запиту та отримання з нього переданих
параметрів;
3. Перевірка даних:
• Співставлення формату отриманих даних та очікуваних. Наприклад
при очікуваному передаванні id що є числом, сервер із запиту
отримав текст;
4. Обробка результату перевірки:
• У разі успішного проходження перевірки дані передаються на
подальші функції;
• Зупинка обробки запиту при виявленні небезпечних даних.

Рис 3.9 – Схема перевірки даних
Для роботи з базою даних було завантажено та встановлено СУБД
PostgreSQL. Після встановлення було створено та налаштовано базу даних для
роботи з системою. Для забезпечення безпеки виконалося встановлення паролю
для отримання доступу до бази даних.
Після проходження всіх налаштувань було виконано підключення до бази
даних з коду сервер.
Арк.
ЧДТУ.23.22187.002.ПЗ
6 3
Змн. Арк. № докум. Підпис Дата

Рис 3.10 – Підключення до бази даних

Для створення запитів до бази даних було використано параметризовані
запити так як вони забезпечать додаткову перевірку даних перед надсиланням їх
у базу даних. Для створення на відправки запитів використано доступний
функціонал бібліотеки pg-pool.

Рис 3.11 – Приклад створення параметризованого запиту

Третім заключим етапом у забезпеченні захисту від ін’єкцій є перевірка
надісланих користувачем файлів. В розробленій системі збереження даних
відбувається шляхом відправки бінарних даних файлу та збереження їх у базі
даних.
Для забезпечення цього функціоналу, у клієнтському додатку реалізував
інтерфейс що дозволяє користувачу вибрати файл та завантажити його. Після
чого додаток обробляє файл формує тіло запиту та відправляє дані на сервер.
Сервер приймає запит, аналізує дані файлу що були передані, виконує
перевірку їх на вміст шкідливого ПЗ, та у разі успішної перевірки виконує
збереження бінарних даних файлу у базу даних. Після входження в систему
користувачу буде доступна інформація про назву завантаженого файлу та його
тип, по кліку на його назву відбувається завантаження файлу з серверу.
Арк.
ЧДТУ.23.22187.002.ПЗ
6 4
Змн. Арк. № докум. Підпис Дата

Рис 3.12 – Інтерфейс для відправки файлів на сервер.

Для впровадження системи перевірки отриманих файлів виконав наступні
дії:
1. Встановив системи ClamAV;
2. Встановив бібліотеку «clamcan» для взаємодії з системою ClamAV;
3. Налаштував з’єднання:
Після встановлення всіх потрібних компонентів потрібно імпортував
бібліотеку в коді, та створив новий екземпляр ClamScan;
4. Сканування файлів:
При отриманні запиту сервер обробляє його, отримує з нього файл, та
передає його методу «scanFile» для сканування файлу на віруси.
5. Обробка результату:
• Якщо після перевірки метод повернув значення «OK», це означає що
файл чистий і не містить вірусів.
• Якщо метод повернув значення відмінне від «OK» це означає що
файл інфіковано і метод повернув назву виявленого вірусу.

Арк.
ЧДТУ.23.22187.002.ПЗ
6 5
Змн. Арк. № докум. Підпис Дата

Рис 3.13 – Структура коду для перевірки файлів

3.5 Впровадження моніторингу та журналювання

Для впровадження моніторингу та журналювання подій у системі
використав дві бібліотеки: Winston та Morgan. Для реалізації їх поєднаної роботи
виконав ряд дій, а саме:
1. Встановив та налаштував Winston:
• Встановив бібліотеку Winston;
• Налаштував параметри логування та вибір місця збереження даних;
• Створив функції для отримання та логування інформації, та
впровадив їх в місцях взаємодії окремих елементів системи;
2. Встановив та налаштував Morgan:
• Встановив бібліотеку Morgan;
• Налаштував параметри логування та вибір даних які потребують
збереження;
• Створив функції отримання запитів, їх обробки та вибірки даних для
логування. Впровадив функції в елементи системи які відповідають
за обробку запитів від користувача;
• Налаштував передачу даних на відповідні функції Winston для їх
централізованого збереження.

Арк.
ЧДТУ.23.22187.002.ПЗ
6 6
Змн. Арк. № докум. Підпис Дата

Структура коду для взаємодії цих двох систем має наступний вигляд:

Рис 3.14 – Налаштування Winston

Рис 3.15 – Налаштування Morgan

3.6 Огляд структури розробленої системи

Розробка продуманої та безпечної структури клієнт-серверної системи для
передачі даних є важливою з численних причин, це і масштабованість системи,
ефективна взаємодія всіх її складових, стандартизація, легкість у керованості
системи та впроваджені нового функціоналу.
Арк.
ЧДТУ.23.22187.002.ПЗ
6 7
Змн. Арк. № докум. Підпис Дата

При створенні даної системи мною було розроблено клієнтський додаток
та сервер, кожна з цих частин системи має свою продуману структуру яка
дозволить забезпечити надійну роботу системи.
Структура клієнтського додатка має наступний вигляд:
1. Головний файл App;
2. Головні компоненти «auth/reg»;
3. Підкомпоненти:
• authentication»;
• registration;
• chat;
• message;
4. Виконавчі функції.

Рис 3.16 – Структура клієнтського додатку

Арк.
ЧДТУ.23.22187.002.ПЗ
6 8
Змн. Арк. № докум. Підпис Дата

Серверна сторона являє собою розроблений за допомогою Node.js сервер
який обробляє запити користувача за реалізує функціонал що забезпечує безпеку
системи.
Структура серверу складається з таких частин:
1. Головний маршрутизатор;
2. Middleware;
3. Маршрутизатори нижчого рівня;
4. Контролери;
5. Виконавчі функції

Рис 3.17 – Структура серверу

Арк.
ЧДТУ.23.22187.002.ПЗ
6 9
Змн. Арк. № докум. Підпис Дата

3.7 Тестування інформаційної безпеки системи

3.7.1 Важливість тестування, огляд засобів тестування
Забезпечення інформаційної безпеки у клієнт-серверних системах є
надзвичайно важливим елементом, оскільки ці системи виставлені на постійну
загрозу з боку різноманітних атак та кіберзлочинів. З моменту з'єднання клієнтів
і серверів виникає необхідність надійної системи захисту конфіденційної
інформації, а також забезпечення доступу тільки авторизованим користувачам.
При розробці захищеної системи особливо важливим є процес тестування
який дозволить ще до впровадження системи в роботу оцінити її рівень захисту,
та допомогти його покращити.
Важливість тестування:
1. Виявлення вразливостей:
• Тестування інформаційної безпеки в клієнт-серверних системах
визначає вразливості, які можуть бути використані для
несанкціонованого доступу, витоку інформації чи інших атак.
Передбачення та усунення цих вразливостей є ключовим етапом для
забезпечення стійкості системи;
2. Захист важливих даних:
• Тестування допомагає перевірити ефективність заходів забезпечення
інформаційної безпеки та визначити, наскільки ефективно система
захищає важливі дані. Це необхідно для запобігання
несанкціонованому доступу та недопущення витоку конфіденційної
інформації;
3. Ефективність заходів:
• Оцінка інформаційної безпеки дозволяє визначити, наскільки
ефективні заходи безпеки в контексті конкретної клієнт-серверної
системи. Це важливо для постійного удосконалення та адаптації
стратегій забезпечення безпеки до середовища кіберзагроз які
постійно змінюються.
Арк.
ЧДТУ.23.22187.002.ПЗ
7 0
Змн. Арк. № докум. Підпис Дата

Для тестування розробленої системи мною було використано відкрите
програмне забезпечення для тестування веб-додатків OWASP Zed Attack Proxy
(OWASP ZAP). ZAP є одним із проектів OWASP та надає інструменти для
виявлення різноманітних вразливостей у веб-додатках. Основною метою ZAP є
допомога розробникам у покращенні безпеки своїх систем.
Ключові характеристики OWASP ZAP:
1. Пасивне та активне сканування:
• OWASP ZAP включає як пасивні, так і активні методи сканування.
Пасивне сканування дозволяє виявляти вразливості, не надсилаючи
активних запитань серверу, тим самим уникнувши зайвого
навантаження на додаток. Активне сканування включає в себе
спроби вразливих атак з метою виявлення конкретних проблем
безпеки;
2. Інтерактивний інтерфейс:
• OWASP ZAP має користувацький інтерфейс, який дозволяє
користувачам легко взаємодіяти з інструментом та аналізувати
результати сканування;
3. Можливості перехоплення та зміни запитань та відповідей:
• Користувач може використовувати OWASP ZAP для перехоплення
та зміни запитань та відповідей між клієнтом і сервером. Це дозволяє
аналізувати, модифікувати та тестувати вразливості в реальному
часі;
OWASP ZAP може використовуватися для перевірки системи на
вразливість до різноманітних атаках. Широкий перелік атак які можна
протестувати дозволяє всебічно проаналізувати захист системи да якнайкраще
захистити систему від реальних атак. Деякі типи атак які можна провести або
виявити за допомогою ZAP включають:
1. SQL Injection (SQLI):
• ZAP може виявляти та тестувати на вразливості, пов'язані із SQL-
ін'єкціями, які можуть дозволити несанкціонований доступ до бази

Арк.
ЧДТУ.23.22187.002.ПЗ
7 1
Змн. Арк. № докум. Підпис Дата

даних через некоректно оброблені SQL-запити;
2. Cross-Site Scripting (XSS):
• ZAP виявляє XSS-вразливості, які можуть призвести до виконання
скриптів у браузері користувача через некоректну обробку введених
даних;
3. Cross-Site Request Forgery (CSRF):
• За допомогою ZAP можна тестувати на CSRF-атаки, коли
зловмисник намагається використовувати авторизовану сесію
користувача для виконання некоректних дій без його дозволу;
4. Security Misconfigurations:
• ZAP виявляє проблеми безпеки, пов'язані з некоректними
конфігураціями веб-додатків, такі як невірні налаштування прав
доступу чи виток чутливої інформації через погану конфігурацію;
5. Insecure Direct Object References (IDOR):
• ZAP виявляє атаки, пов'язані з некоректною обробкою посилань на
об'єкти, які можуть дозволити несанкціонований доступ до ресурсів;
6. Security Headers:
• ZAP допомагає перевіряти використання правильних заголовків
безпеки, таких як Content Security Policy (CSP) та HTTP Strict
Transport Security (HSTS);
7. Authentication and Session Management Issues:
• ZAP дозволяє тестувати на проблеми аутентифікації та управління
сесіями, такі як слабкі паролі, атаки на фіксацію сесії і т. д.
Це лише кілька типів атак, які можуть бути виявлені або протестовані за
допомогою OWASP ZAP. Інструмент Є потужним і дозволяє виявляти широкий
спектр вразливостей для підвищення безпеки веб-додатків.

3.7.2 Результати тестування системи.
При розробці системи було проведене автоматичне тестування за
допомогою ZAP. В ході тестування було перевірено дві складові системи:

Арк.
ЧДТУ.23.22187.002.ПЗ
7 2
Змн. Арк. № докум. Підпис Дата

1. Початкова сторінка:
• Містить інтерфейс та функціонал для проведення реєстрації та
автентифікації користувача перед входом в систему;
2. Домашня сторінка системи:
• Містить інтерфейс та функціонал що забезпечує всю роботу
користувача з даними на сервері. Забезпечує створення чатів з
іншими користувачами, відправку на сервер текстових повідомлень,
відправку та завантаження файлів.
Тестування системи проводилося автоматично, що дозволило
пришвидшити процес тестування, забезпечити коректну перевірку за всіма
найпоширенішими загрозами та методами атак.
Результатами перевірки став згенерований звіт та перелік знайдених
вразливостей за такими категоріями: висока загроза, середня загроза, низька
загроза, та занадто висока поінформованість. Загроз високо рівня, та загроз
пов’язаних з високою поінформованістю користувача не було виявлено

Рис 3.18 – Загрози середнього рівня

При проведенні тестування було знайдено три типи вразливостей
середнього рівня:
1. Відсутність заголовку для захисту від клікджекінгу:
Клікджекінг - це вид атаки на безпеку веб-додатків, при якому зловмисник
Арк.
ЧДТУ.23.22187.002.ПЗ
7 3
Змн. Арк. № докум. Підпис Дата

намагається обманути користувача, щоб той випадково або несвідомо виконав
певні дії на веб-сайті без його відома чи згоди. У такому випадку зловмисник
розміщає невидимий або прихований елемент (наприклад, кнопку або
посилання) поверх видимого та привертає увагу користувача, який потім
ненавмисно клікає на цей прихований елемент.

Рис 3.19 – Сповіщення про загрозу клікджекінгу

2. Заголовок політики безпеки вмісту не встановлено:
Заголовок політики безпеки вмісту (Content-Security-Policy) вказує
браузеру, як взаємодіяти з ресурсами на сторінці. Відсутність заголовка політики
безпеки вмісту (Content Security Policy, CSP) може збільшити ризик
різноманітних атак на безпеку, зокрема атак типу Cross-Site Scripting (XSS).
Щоб виправити цю проблему, слід додати заголовок CSP веб-сайту.
Правильно налаштований CSP може включати в себе вказівки щодо джерел, з
яких можна завантажувати ресурси, включаючи скрипти, стилі, зображення і т.
д. Приклад базового CSP-заголовка: Content-Security-Policy: default-src 'self';
3. Неправильна міждоменна конфігурація:
Неправильна конфігурація CORS на сервер дозволяє міждоменні запити на
читання від сторонніх доменів. Ця неправильна конфігурація може бути
використана зловмисниками для доступу до даних у неавтифікований доступ.
Арк.
ЧДТУ.23.22187.002.ПЗ
7 4
Змн. Арк. № докум. Підпис Дата

Для усунення цієї загрози слід налаштувати конфігурацію та переконатися
що конфіденційні дані не доступні без автентифікації.

Рис 3.20 – Сповіщення про неправильну міждоменну конфігурацію

Також було знайдено два типи вразливостей низького рівня:

Рис 3.21 – Загрози низького рівня

1. Пропуск інформації через заголовок відповіді:
Веб сервер пропускає інформацію через один або кілька заголовків HTTP
відповідей «X-Powered-By». Доступ до такої інформації може полегшити
Арк.
ЧДТУ.23.22187.002.ПЗ
7 5
Змн. Арк. № докум. Підпис Дата

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

Рис 3.22 – Сповіщення про загрозу витоку інформаціє через заголовок
«X-Powered-By».
2. Відсутність заголовка X-Content-Type-Options:

Рис 3.23 – Сповіщення про відсутність заголовка X-Content-Type-Options

У заголовку Anti-MIME-Sniffing X- Content-Type-Options не встановлено
значення «nosniff». Це дозволить старим версіям Internet Explorer і Chrome
Арк.
ЧДТУ.23.22187.002.ПЗ
7 6
Змн. Арк. № докум. Підпис Дата

виконувати MIME- розпізнавання вмісту відповіді що потенційно може
призвести до інтерпретації та відображення вмісту відповіді.

3.7.3 Аналіз результатів та визначення заходів що до усунення виявлених
загроз
Проаналізувавши результати тестування можна прийти до висновку що
практично всі знайдені загрози пов’язані з не належним налаштуванням
конфігурації системи, та відсутністю потрібних заголовків у відповідях сервера.
Що стосується позитивної сторони тестування то це те що в системі не
було виявлено загроз високого рівня. Такі аспекти роботи системи як генерація,
збереження та відправка токену мають належний рівень безпеки. Також при
тестуванні не було виявлено вразливостей що можуть призвести до виникнення
SQL ін’єкцій.
Для усунення виявлених загроз був виконаний ряд дій з налаштування
серверу.
Таблиця 3.1 Заходи щодо усунення виявлених загроз
Загроза Захід для усунення
Відсутність заголовку для захисту від Додавання заголовку «X-Frame-
клікджекінгу Options» зі значенням «DENY»
Відсутність заголовку політики Додавання заголовку політики
безпеки вмісту (CSP) безпеки вмісту «Content-Security-
Policy» та встановлення параметра
«default-src 'self'»
Неправильна міждоменна Налаштування серверу для дозволу
конфігурація (CORS) надсилання запитів лише з довірених
джерел «Access-Control-Allow-Origin»
Пропуск інформації через заголовок Вимкнення автоматичного включення
відповіді заголовку «X-Powered-By» у
налаштуваннях сервера
Арк.
ЧДТУ.23.22187.002.ПЗ
7 7
Змн. Арк. № докум. Підпис Дата

Відсутність заголовку X-Content- Додавання заголовку «X-Content-
Type-Options Type-Options» з параметром «nosniff»

Висновки до розділу 3

Даний розділ дипломного проекту присвячений розробці та тестуванню
системи обміну даними на основі клієнт-серверної архітектури.
Розділ описує програмну реалізацію системи, та розповідає про
впровадження наступного функціоналу:
• створення захищеного з’єднання за допомогою протоколу HTTPS;
• впровадження реєстрації та двофакторної автентифікації,
• генерація, відправка, та перевірка токена;
• створення систем захисту від ін’єкцій;
• впровадження моніторингу та журналювання;
Також було досліджено важливість проведення тестування для
забезпечення надійності та стійкості системи. Виконано огляд засобів
тестування, зокрема висвітлена система OWASP ZAP, яка була використана для
оцінки безпеки клієнт-серверної системи.
Подано результати тестування, в яких розглядаються виявлені вразливості
системи, що їх спричиняє та як з цим боротися. Цей аналіз стає ключовим для
розуміння потенційних ризиків та прийняття кроків для їх подальшого усунення.

Арк.
ЧДТУ.23.22187.002.ПЗ
7 8
Змн. Арк. № докум. Підпис Дата

ЗАГАЛЬНІ ВИСНОВКИ

В ході виконання роботи мною було розроблено захищену систему обміну
даними на основі клієнт-серверної архітектури. Дана робота є актуальною у
зв’язку з тим що системи обміну даними стають необхідністю, оскільки вони не
лише сприяють оптимізації роботи, а й забезпечують надійний механізм обробки
та зберігання інформації в умовах сучасного технологічного прогресу.
Розвиток цієї сфери визначає новий рівень можливостей для вирішення
завдань, пов'язаних із забезпеченням інформаційної безпеки та оптимізацією
обміну даними в онлайн середовищі.
Розробка в рамках кваліфікаційної роботи захищеної системи обміну
даними на основі клієнт-серверної архітектури дозволила створити механізм, що
відповідає високим стандартам інформаційної безпеки та ефективності.
Використання передових технологій у сфері криптографії, автентифікації
та мережевих протоколів дозволило побудувати надійний бар'єр для захисту
важливих даних від несанкціонованого доступу.
Проведення тестування системи на наявні вразливості дозволило краще
зрозуміти рівень забезпечення безпеки, та вказало напрямок для вдосконалення
наявних систем захисту.
Під час виконання роботи були досягнуті всі поставлені завдання а саме:
• Визначено основний функціонал системи;
• Досліджено нормативну базу у сфері захисту клієнт-серверних систем;
• Проведено пошук та аналіз поширених загроз інформаційній безпеці
притаманних клієнт-серверним системам;
• Створено структуру проекту та визначено задіяні системи захисту;
• Створено програмну реалізацію що являє собою сервер для обробки та
зберігання інформації, та клієнтську частину для взаємодії з сервером;
• Проведено тестування розробленої системи.

Арк.
ЧДТУ.23.22187.002.ПЗ
7 9
Змн. Арк. № докум. Підпис Дата

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. NIST SP 800-53 - https://nvlpubs.nist.gov/nistpubs/SpecialPublication/NIST.
SP.800-53r5.pdf;
2. GDPR - https://eur-lex.europa.eu/legalcontent/EN/TXT/PDF/?uri=CELEX:
32016R0679;
3. Закон України «Про захист персональних даних» - https://zakon.rada.gov.
ua/laws/show/2297-17#Text;
4. OWASP - https://owasp.org/;
5. CVE - https://cve.mitre.org/;
6. NVD - https://nvd.nist.gov/;
7. Node.js - https://nodejs.org/docs/latest/api/;
8. JWT (JSON Web Token) - https://jwt.io/;
9. PostgreSQL - https://www.postgresql.org/docs/;
10. Securing DevOps" by Julien Vehent - https://www.oreilly.com/library/view/
securing-devops/9781491978847/;
11. OAuth 2.0 Simplified" by Aaron Parecki - https://www.oauth.com/oauth2-
servers/access-tokens/;
12. The Web Application Hacker's Handbook" by Dafydd Stuttard and Marcus
Pinto - https://owasp.org/images/7/72/Web_Application_Hackers_Handbook.
Pdf;
13. "Web Security Testing Cookbook" by Paco Hope and Ben Walther - https://
www.oreilly.com/library/view/web-security-testing/9781849518721/;
14. OWASP Testing Guide" by OWASP - https://owasp.org/www-project-web-
security-testing-guide/.

Арк.
ЧДТУ.23.22187.002.ПЗ
8 0
Змн. Арк. № докум. Підпис Дата

Додаток А

Код програмної реалізації захищеної системи обміну даними на основі
клієнт-серверної архітектури

1. Код клієнтського додатку

Рис 1.1 – Код головного файлу App

Рис 1.2 – Код обробки подій при реєстрації
Арк.
ЧДТУ.23.22187.002.ПЗ
8 1
Змн. Арк. № докум. Підпис Дата

Рис 1.3 – Код для відображення інтерфейсу реєстрації

Рис 1.4 – Код для обробки подій при автентифікації

Рис 1.5 – Код для відображення інтерфейсу при автентифікації

Арк.
ЧДТУ.23.22187.002.ПЗ
8 2
Змн. Арк. № докум. Підпис Дата

Рис 1.6 – Код для обробки подій домашньої сторінки

Рис 1.7 – Код для відображення інтерфейсу домашньої сторінки

Рис 1.8 – Код для обробки подій пов’язаних зі списком чатів

Арк.
ЧДТУ.23.22187.002.ПЗ
8 3
Змн. Арк. № докум. Підпис Дата

Рис 1.9 – Код для відображення списку чатів

Рис 1.10 – Код для завантаження надісланих даних

Арк.
ЧДТУ.23.22187.002.ПЗ
8 4
Змн. Арк. № докум. Підпис Дата

Рис 1.11 – Код для відображення завантажених даних

Рис 1.12 – Код для обробки введених користувачем даних

Рис 1.13 – Код інтерфейсу для отримання даних користувача

Арк.
ЧДТУ.23.22187.002.ПЗ
8 5
Змн. Арк. № докум. Підпис Дата

Рис 1.14 – Код відправки запитів на сервер

Рис 1.15 – Код відправки запитів на сервер з домашньої сторінки

Арк.
ЧДТУ.23.22187.002.ПЗ
8 6
Змн. Арк. № докум. Підпис Дата

2. Код серверу

Рис 2.1 – Код головного маршрутизатора серверу

Рис 2.2 – Код Middleware для перевірки токену

Рис 2.3 – Код маршрутизаторів нижчого рівня

Рис 2.4 – Код підключення до бази даних
Арк.
ЧДТУ.23.22187.002.ПЗ
8 7
Змн. Арк. № докум. Підпис Дата

Рис 2.5 Код контролерів

Рис 2.6 Код додавання нового користувача в систему

Арк.
ЧДТУ.23.22187.002.ПЗ
8 8
Змн. Арк. № докум. Підпис Дата

Рис 2.7 – Код перевірки даних для реєстрації

Рис 2.8 – Код авторизації користувача

Арк.
ЧДТУ.23.22187.002.ПЗ
8 9
Змн. Арк. № докум. Підпис Дата

Рис 2.9 – Код отримання списку чатів

Рис 2.10 – Код створення нового чату

Рис 2.11 – Код отримання повідомлень чату

Арк.
ЧДТУ.23.22187.002.ПЗ
9 0
Змн. Арк. № докум. Підпис Дата

Рис 2.12 – Код обробки та додавання повідомлення в базу даних

Рис 2.13 – Код зберігання файлу в базі даних

Рис 2.14 – Код для отримання файлу з бази даних

Арк.
ЧДТУ.23.22187.002.ПЗ
9 1
Змн. Арк. № докум. Підпис Дата

Додаток Б

Мультимедійна презентація

Рис 1 - Титульний слайд

Рис 2 – Мета та завдання роботи

Арк.
ЧДТУ.23.22187.002.ПЗ
9 2
Змн. Арк. № докум. Підпис Дата

Рис 3 – Актуальність теми

Рис 4 – Визначення загальної структури та функціоналу системи

Арк.
ЧДТУ.23.22187.002.ПЗ
9 3
Змн. Арк. № докум. Підпис Дата

Рис 5 – Визначення можливих загроз безпеці системи

Рис 6 – Заходи щодо забезпечення безпеки системи

Арк.
ЧДТУ.23.22187.002.ПЗ
9 4
Змн. Арк. № докум. Підпис Дата

Рис 7 – Схема роботи HTTPS протоколу

Рис 8 – Реєстрація та автентифікація

Арк.
ЧДТУ.23.22187.002.ПЗ
9 5
Змн. Арк. № докум. Підпис Дата

Рис 9 – Робота з токеном

Рис 10 – Захист він ін’єкцій

Арк.
ЧДТУ.23.22187.002.ПЗ
9 6
Змн. Арк. № докум. Підпис Дата

Рис 11 – Моніторинг та журналювання

Рис 12 – Тестування розробленої системи

Арк.
ЧДТУ.23.22187.002.ПЗ
9 7
Змн. Арк. № докум. Підпис Дата

Рис 13 – Висновок

Арк.
ЧДТУ.23.22187.002.ПЗ
9 8
Змн. Арк. № докум. Підпис Дата

Репозиторій ЧДТУ