ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7781| Title: | Аналіз методів розробки захищених веб-додатків, їх систематизація та впровадження |
| Authors: | Палагін, Володимир Васильович Мироненко, Михайло Дмитрович |
| Keywords: | захист веб-додатків;ssl/tls сертифікати;waf (брандмауер веб-додатків);ids/ips системи;кібербезпека мережі;python |
| Issue Date: | 2022 |
| Abstract: | Метою роботи є проведення аналізу широкого спектру методів, що застосовуються для забезпечення захисту у веб-додатках, систематизація та класифікація цих методів, та розробка методики створення системи методів захисту та її впровадження. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7781 |
| Appears in Collections: | 125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| М_125_Мироненко_Палагін.pdf Restricted Access | 2.53 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ЕЛЕКТРОННИХ ТЕХНОЛОГІЙ, АВТОТРАНСПОРТУ ТА
МАШИНОБУДУВАННЯ
КАФЕДРА РОБОТОТЕХНІЧНИХ І ТЕЛЕКОМУНІКАЦІЙНИХ СИСТЕМ ТА
КІБЕРБЕЗПЕКИ
До захисту допущено
завідувач кафедри РТСК
д.т.н., професор
_______________ В.В. Палагін
"_____" _____________ 2022 року
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему «Аналіз методів розробки захищених веб-додатків, їх систематизація
та впровадження»
Виконав: студент 2 курсу, групи БІ-011
Спеціальності 125 – «Кібербезпека» ,
(шифр і назва спеціальності)
освітньої програми «Безпека інформаційних і
комунікаційних систем»
(назва освітньої програми)
Мироненко М.Д.
(прізвище та ініціали)
Керівник Палагін В.В.
(прізвище та ініціали)
Рецензент Андрієнко В.О.
(прізвище та ініціали)
Черкаси – 2022 року
Форма № Н-9.01
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет електронних технологій, автотранспорту та машинобудування
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки
Освітньо-кваліфікаційний рівень магістр
Спеціальність 125 – Кібербезпека
Освітня програма – Безпека інформаційних і комунікаційних систем
ЗАТВЕРДЖУЮ
Завідувач кафедри В.В. Палагін
“_____” ___________________ 2022 року
ЗАВДАННЯ
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Мироненка Михайла Дмитровича _____________________
(прізвище, ім’я, по батькові)
1. Тема проекту (роботи) Аналіз методів розробки захищених веб-додатків, їх
систематизація та впровадження
керівник проекту (роботи) Палагін Володимир Васильович
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом вищого навчального закладу від «___» __________ 2022 року № ___
2. Термін здачі студентом закінченої роботи “ 10 ”грудня 2022 року __________
3. Вихідні дані до роботи: Використання сертифікатів SSL/TLS; встановлення та
використання WAF (брандмауер веб-додатків); впровадження IPS або IDS; забезпечення
високого рівня безпеки мережі; мова програмування – Python.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити)
Аналіз принципів побудови захищених веб-додатків; Аналіз методів захисту, що
впроваджуються та застосовуються на етапі розробки веб-додатку; Створення
методики впровадження системи методів захисту на основі проведеного аналізу.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів)
1. Аналіз принципів побудови захищених веб-додатків; 2. Аналіз методів захисту, що
впроваджуються та застосовуються на етапі розробки веб-додатку; 3. Створення
методики впровадження системи методів захисту на основі проведеного аналізу;
.6. Консультанти з проекту (роботи) із зазначенням розділів проекту, що їх стосуються
Прізвище, ініціали та посада Підпис, дата
Розділ консультанта завдання завдання
видав прийняв
7. Дата видачі завдання
КАЛЕНДАРНИЙ ПЛАН
№ Назва етапів дипломного проекту Термін
з/п (роботи) виконання етапів Примітка
проекту (роботи)
1. Аналіз технічного завдання та пошук
літератури 18.09.22 – 09.10.22
2. Аналіз принципів побудови методів розробки
захищених веб-додатків 10.10.22 – 24.10.22
3. Створення методики впровадження системи
методів захисту на основі проведеного аналізу 25.10.22 – 10.11.22
4. Аналіз та верифікація отриманого рішення 11.11.22 – 25.11.22
7. Виконання розділу охорони праці 11.11.22 – 26.11.22
8. Оформлення пояснювальної записки 27.11.22 – 01.12.22
9. Оформлення презентації 02.12.22 – 09.12.22
Студент Мироненко М.Д..
( підпис ) (прізвище та ініціали)
Керівник проекту (роботи) Палагін В.В.
( підпис ) (прізвище та ініціали)
Зміст
ВСТУП ................................................................................................................ 6
РОЗДІЛ 1: АНАЛІЗ ТА СИСТЕМАТИЗАЦІЯ МЕТОДІВ ЩО
ЗАСТОСОВУЮТЬСЯ НА ЕТАПІ ПІДГОТОВКИ ДО РОЗРОБКИ ...... 8
1.1. Аналіз правової документації .................................................................. 8
1.2. Аналіз методів захисту що застосовуються на етапі налагодження
інфраструктури ................................................................................................. 9
1.2.1. Методи захисту офісу та/або серверної ............................................... 9
1.2.2. Аналіз етапу налаштування мережі компанії ................................. 10
1.2.3. Аналіз методів захисту кінцевих пристроїв інфраструктури ...... 16
1.3. Аналіз етапу підготовки працівників .................................................. 16
1.3.1. Аналіз основних тем для навчальної програми працівників ...... 17
1.4. Висновки до розділу ................................................................................ 24
РОЗДІЛ 2: АНАЛІЗ МЕТОДІВ ЗАХИСТУ, ЩО
ВПРОВАДЖУЮТЬСЯ ТА ЗАСТОСОВУЮТЬСЯ НА ЕТАПІ
РОЗРОБКИ ВЕБ-ДОДАТКУ ........................................................................ 25
2.1. Аналіз методів автентифікації та авторизації ................................... 26
2.1.1. Аналіз методу автентифікації на основі форм ................................ 26
2.1.2. Аналіз методу автентифікації по сертифікату ................................ 28
2.1.3. Аналіз методу автентифікації на основі одноразових паролів .... 31
2.1.4. Аналіз методу автентифікації на основі ключів доступу ............. 32
2.1.5. Аналіз методу автентифікації на основі токенів ............................ 34
2.2. Аналіз загальних методів виявлення вразливостей. ........................ 36
2.2.1. Аналіз методу впровадження аудиту та журналювання. ............. 37
ЧДТУ.22.21091.006 ПЗ
Зм. Арк. № докум. Підпис Дата
Розроб. Мироненко М.Д. Аналіз методів розробки Літ. Аркуш Аркушів
Перевір. Палагін В.В. захищених веб-додатків, їх 4 83
систематизація та
Н.Контрол. Палагін В.В. впровадження ЧДТУ, БІ-011
Затвердж. Кунченко-Харченко В.І.
2.2.2. Аналіз методу ретельного контролю якості та тестування на
проникнення .................................................................................................... 37
2.2.3. Аналіз методу впровадження статичних аналізаторів коду ........ 39
2.3. Аналіз загальних методів попередження/ліквідації вразливостей 40
2.3.1. Аналіз методу регулярних оновлень бібліотек та інших
залежностей проекту ...................................................................................... 40
2.3.2. Аналіз методу обробки вхідних даних .............................................. 41
2.3.3. Аналіз методу впровадження протоколу SSL/TLS ........................ 42
2.4. Аналіз спеціалізованих методів захисту .............................................. 43
2.4.1. Аналіз методів протидії SQL-ін’єкціям ............................................ 43
2.4.2. Аналіз методів захисту проти XSS атак ........................................... 48
2.4.3. Аналіз методів захисту проти CSRF атак ........................................ 52
2.4.4. Аналіз методів захисту проти атаки Path traversal ........................ 63
2.4.5. Аналіз методів захисту проти атаки XML External Entity ........... 65
2.4.6. Аналіз методів захисту проти атаки Clickjacking .......................... 66
2.4.7. Висновки до розділу ............................................................................. 67
РОЗДІЛ 3: СТВОРЕННЯ МЕТОДИКИ ВПРОВАДЖЕННЯ
СИСТЕМИ МЕТОДІВ ЗАХИСТУ НА ОСНОВІ ПРОВЕДЕНОГО
АНАЛІЗУ .......................................................................................................... 69
3.1. Виявлення впливу методів застосованих на етапі підготовки ....... 69
3.2. Визначення можливості впровадження методу................................. 70
3.3. Визначення необхідності впровадження методу. .............................. 70
3.4. Визначення пріоритету впровадження методу. ................................. 73
3.5. Висновки до розділу ................................................................................ 80
ВИСНОВОК ..................................................................................................... 81
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................... 82
Лист
ЧДТУ.22.21091.006 ПЗ
Зм Арк №Докум. Підп Дат 5
а
ВСТУП
Актуальність теми. неспроможність захистити конфіденційну
інформацію від розголошення може спричинити безліч проблем для
організацій:
Втрата бізнесу: неправильне використання конфіденційної
інформації може викликати відчуття недовіри з боку клієнтів, що
негативно впливає на прибутки компанії.
Злочинна діяльність: якщо конфіденційну інформацію
використовують для злочинної діяльності, наприклад шахрайства, це
ненавмисно заплямує репутацію компанії.
Втрата конкурентної переваги: коли бізнес-плани, інтелектуальна
власність або комерційні таємниці розголошуються незаконно, це
ставить компанію під загрозу втрати конкурентної переваги.
Зниження моралі: коли конфіденційну інформацію про співробітника
викрадають, розповсюджують або розкривають без згоди, це
погіршує довіру роботодавця, впевненість і лояльність.
Відповідність законодавству про конфіденційність: про захист
персональних даних — це закон України, який встановлює правила
щодо того, як компанії можуть збирати, використовувати та
розкривати інформацію про осіб. Якщо організації або роботодавці не
в змозі захистити конфіденційність, вони можуть зіткнутися зі
значними юридичними штрафами за недотримання.
Об’єктом дослідження є методи захисту, що впроваджуються для
запобіганню реалізації загроз.
Предметом дослідження є визначення взаємозв’язків між методами
захисту в процесі розробки веб-додатків та впливу цього фактору на
впровадження методів.
Лист
ЧДТУ.22.21091.006 ПЗ
6
Зм Арк №Докум. Підп Дат
а
Метою роботи є проведення аналізу широкого спектру методів, що
застосовуються для забезпечення захисту у веб-додатках, систематизація та
класифікація цих методів, та розробка методики створення системи методів
захисту та її впровадження.
Наукова новизна полягає в розробці універсальної методики
побудови системи методів захисту, тобто такої, що може бути використана
незалежно від технологій та архітектури додатку до якого вона
застосовується.
Практична цінність розробленого підходу полягає в тому, що
запропонована методика дозволяє спростити та пришвидшити вибір
методів захисту та методів розробки захищеного додатку, а відповідно
зменшити витрати ресурсів на впровадження цих методів, шляхом
визначення можливості, необхідності та пріоритету впровадження тих чи
інших методів.
Актуальність даної роботи обумовлена тим, що на сьогоднішній
день не існує стандартизованого підходу до визначення системи методів чи
окремих методів захисту, в результаті чого методи впроваджуються або за
першою вимогою, або стихійно, що натомість з часом може спричинити
конфлікти між застосованими методами, або призводить до застосування
нерентабельного та неефективного методу. Для вирішення цієї проблеми та
досягнення поставленої мети було виконано наступні завдання:
Проведено аналіз широкого спектру наявних методів захисту та
методів розробки захищених додатків;
Проведено систематизацію та класифікацію розглянутих методів.
На основі проведеного аналізу було розроблено та протестовано
методику впровадження системи методів захисту.
Лист
ЧДТУ.22.21091.006 ПЗ
7
Зм Арк №Докум. Підп Дат
а
РОЗДІЛ 1: АНАЛІЗ ТА СИСТЕМАТИЗАЦІЯ МЕТОДІВ ЩО
ЗАСТОСОВУЮТЬСЯ НА ЕТАПІ ПІДГОТОВКИ ДО РОЗРОБКИ
Перед етапом безпосередньої розробки, обов’язково йде етап
підготовки. Цей етап покликаний підготувати всі аспекти робочого процесу
до безпосередньої розробки, забезпечити інфраструктуру для розробки
додатку, його розгортання та подальшої підтримки. Схема етапу підготовки
наведена нижче (Рисунок 1.1).
Підготовка до розробки
Підготовка та підписання
1 правової документації
2 Налагодження інфраструктури
3 Підготовка працівників
Рисунок 1.1 Схема підготовки до процесу розробки.
1.1. Аналіз правової документації
Першим етапом в підготовці до розробки будь-якого проекту, що
передбачає володіння розробниками певними даними про сам проект,
замовників чи будь яку пов’язану з цим конфіденційну інформацію, є
підписання положення про нерозголошення конфіденційної інформації.
Цей стандарт встановлює порядок віднесення відомостей до таких, що
становлять комерційну таємницю та конфіденційну інформацію
підприємства, організаційні заходи щодо запобігання її витоку, організацію
Лист
ЧДТУ.22.21091.006 ПЗ
8
Зм Арк №Докум. Підп Дат
а
контролю доступу до цих відомостей, права і обов’язки працівників,
відповідальність за втрату або розголошення. Вимоги цього стандарту
повинні знати і виконувати, в межах своїх повноважень та компетенції, всі
працівники Підприємства.
1.2. Аналіз методів захисту що застосовуються на етапі
налагодження інфраструктури
Налагодження інфраструктури, з точки зору безпеки, може включати
в себе наступні пункти:
Створення системи захисту для офісу чи серверної якщо такі
використовуються;
Налаштування мережі компанії;
Налаштування системи захисту та моніторингу кінцевих пристроїв.
Нижче наведено результати аналізу методів захисту, що можуть
застосовуються для кожного з вказаних елементів інфраструктури.
Наведені методи згруповані за ризиками яким вони запобігають.
1.2.1. Методи захисту офісу та/або серверної
Офіс та/або серверна підпадають під наступні ризики [1]:
1) Несанкціоноване проникнення, та його можливі наслідки (втрата
даних, простій серверів, викрадення конфіденційних даних).
Методи захисту:
a) Обмеження доступу до офісу та серверної, наприклад
встановленням електронних замків з фізичними токенами доступу
та біометричними замками, або найм охорони.
b) Впровадження комплексної системи захисту укомплектованої
датчиками (руху, присутності, світла, вібрації, розбиття скла)
2) Стихійні лиха, пожежі, та ризики техногенного характеру.
Методи захисту:
Лист
ЧДТУ.22.21091.006 ПЗ
9
Зм Арк №Докум. Підп Дат
а
a) Впровадження комплексної системи захисту укомплектованої
датчиками (води, замерзання, температури/вологості, диму,
чадного газу)
b) Резервне копіювання даних. Зазвичай цей пункт налаштування
застосовується за замовчуванням оскільки до втрати даних можуть
призвести не тільки стихійні лиха.
c) Перенесення серверів в більш захищений Дата-Центр. Варто
зауважити що в разі перенесення серверних потужностей в Дата-
Центр, система безпеки офісу вже не буде потребувати таких
значних витрат, як у випадку коли сервери знаходяться
безпосередньо в офісі.
Для офісу зазвичай застосовують комплексне рішення в плані
безпеки, тому компанії, що надають послуги з впровадження таких
комплексних систем вже мають готові рішення які попереджують більшу
частину згаданих ризиків, про дані системи детально описано нижче.
1.2.2. Аналіз етапу налаштування мережі компанії
Даний пункт потребує більш детального аналізу, оскільки подальша
розробка проекту та безпека конфіденційних даних, що відносяться до
проекту буде залежати здебільшого від захищеності мережі компанії.
Нижче наведені основні ризики для мережі компанії [2] та методи захисту
що попереджують їх.
1) Проникнення та викрадення конфіденційних даних.
Методи захисту:
a) Впровадження VPN.
VPN (віртуальна приватна мережа) шифрує підключення до
Інтернету та дані, що передаються через мережу. Більшість служб
VPN також мають вбудовану функцію (перемикач блокування),
яка від’єднує апаратне забезпечення від мережі, коли втрачається
Лист
ЧДТУ.22.21091.006 ПЗ
10
Зм Арк №Докум. Підп Дат
а
захищене з’єднання, таким чином убезпечуючи вас від
несподіваного витоку даних. Крім того, за допомогою VPN ваші
співробітники можуть безпечно використовувати Wi-Fi під час
віддаленої роботи без шкоди для конфіденційних даних компанії.
Для більшої захищеності можна налаштувати двох-факторну
автентифікацію для входу в мережу.
b) Впровадження WPA2.
Використовуйте надійний зашифрований протокол для паролів на
маршрутизаторі для бізнес-мережі. Найдосконалішим є WPA (Wi-
Fi Protected Access). Переконайтеся, що цей протокол увімкнено у
мережевому маршрутизаторі.
c) Відключення або обмеження DHCP.
DHCP (протокол динамічної конфігурації хоста) визначає, які IP-
адреси матимуть пристрої у мережі. Це полегшує підтримку
мережі Wi-Fi. Проте, щоб зробити його більш безпечним, обмежте
кількість IP-адрес, призначених DHCP, або повністю вимкніть цю
функцію. Останній варіант означає, що потрібно буде вручну
призначити IP-адресу для кожного пристрою, підключеного до
вашої Wi-Fi.
d) Відключення спільного доступу до файлів.
Спільний доступ до файлів слід увімкнути лише на файлових
серверах. Якщо ви ввімкнете спільний доступ до файлів на всіх
пристроях, підключених до вашої мережі Wi-Fi, файли, передані
через неї, бачитимуть усі інші користувачі цього з’єднання Wi-Fi.
e) Регулярні оновлення прошивки маршрутизатора.
Бізнес-мережа може бути вразливою до хакерських атак через
застарілу мікропрограму маршрутизатора. Хоча оновлення
мікропрограми зазвичай оновлюється принаймні раз на рік,
власники малого бізнесу часто вважають, що оновлення
Лист
ЧДТУ.22.21091.006 ПЗ
11
Зм Арк №Докум. Підп Дат
а
мікропрограми не варте зусиль. Обов’язково оновлюйте
мікропрограму принаймні раз на рік, щоб виправити всі наявні
помилки.
f) Впровадження IPS або IDS.
IDS та IPS є ефективними способами виявлення та запобігання
загрозам. IDS використовується для виявлення будь-яких
зловмисників, таких як шкідливе програмне забезпечення або
хробаки; IPS активно запобігає негативному впливу виявлених
зловмисників.
g) Встановлення WAF.
WAF (брандмауер веб-додатків) захищає конфіденційні дані
клієнтів, які купують послуги або продукти вашої компанії онлайн.
За допомогою WAF інформація клієнта захищена від втручання
хакерів.
h) Використання сертифікатів SSL/TLS.
Щоб виконувати онлайн-транзакції клієнта, необхідно впровадити
протокол TLS не нижче версії 1.2, який забезпечує зашифрований
зв’язок між браузером і веб-сервером.
i) Змініть назву мережі вашої компанії.
Ви не повинні використовувати оригінальну назву вашої мережі,
призначену провайдером. Зазвичай він містить модель вашого
маршрутизатора, який є небезпечним, оскільки його бачать інші
користувачі Інтернету, які можуть знайти необхідну документацію
для отримання доступу до вашої мережі.
2) Атаки на відмову сервісу (DDOS атаки). Даний тип атак може бути
націлений, як на мережу компанії, так і на сам додаток.
Методи захисту:
a) Створення плану реагування на DDoS.
Лист
ЧДТУ.22.21091.006 ПЗ
12
Зм Арк №Докум. Підп Дат
а
Команда безпеки повинна розробити план реагування на
інциденти, який забезпечить оперативне та ефективне реагування
співробітників у разі DDoS. Цей план повинен охоплювати:
Чітка, покрокова інструкція, як реагувати на DDoS-атаку.
Як підтримувати бізнес-операції.
Персонал і ключові зацікавлені сторони.
Протоколи ескалації.
Командні обов'язки.
Контрольний список усіх необхідних інструментів.
Список критично важливих систем.
b) Забезпечення високого рівня безпеки мережі.
Ви можете покластися на такі типи мережевої безпеки, щоб
захистити свій бізнес від спроб DDoS [3]:
Брандмауери та системи виявлення вторгнень, які діють як
бар’єри для сканування трафіку між мережами.
Програмне забезпечення для захисту від вірусів і шкідливих
програм, яке виявляє та видаляє віруси та зловмисне
програмне забезпечення.
Безпека кінцевих точок, яка гарантує, що кінцеві точки
мережі (настільні ПК, ноутбуки, мобільні пристрої тощо) не
стануть точкою входу для зловмисної діяльності.
Інструменти веб-безпеки, які усувають веб-загрози,
блокують ненормальний трафік і шукають відомі сигнатури
атак.
Інструменти, які запобігають спуфінгу, перевіряючи, чи
адреса джерела трафіку збігається з адресами походження.
Лист
ЧДТУ.22.21091.006 ПЗ
13
Зм Арк №Докум. Підп Дат
а
Сегментація мережі, яка розділяє системи на підмережі з
унікальними елементами керування безпекою та
протоколами.
Захист від DDoS-атак також вимагає високого рівня безпеки
мережевої інфраструктури. Захист мережевих пристроїв дає
змогу підготувати ваше обладнання (маршрутизатори,
балансувальники навантаження, системи доменних імен
(DNS) тощо) до стрибків трафіку.
c) Впровадження серверного резервування.
Покладаючись на кілька розподілених серверів, хакеру важко
атакувати всі сервери одночасно. Якщо зловмисник запускає
успішний DDoS на одному хостинговому пристрої, інші сервери
залишаються незмінними та приймають додатковий трафік, доки
цільова система не відновиться в мережі. Ви повинні розміщувати
сервери в центрах обробки даних і в об’єктах спільного
розміщення в різних регіонах, щоб у вас не було жодних вузьких
місць у мережі чи окремих точок збою. Ви також можете
використовувати мережу доставки контенту (CDN). Оскільки
DDoS-атаки діють шляхом перевантаження сервера, CDN може
порівну розподілити навантаження між кількома розподіленими
серверами.
d) Моніторинг попереджувальних знаків.
Якщо команда безпеки може швидко визначити ознаки DDoS-
атаки, то вона зможете вчасно вжити заходів і зменшити шкоду.
Загальні ознаки DDoS:
Погане підключення.
Повільна продуктивність.
Високий попит на одну сторінку або кінцеву точку.
Лист
ЧДТУ.22.21091.006 ПЗ
14
Зм Арк №Докум. Підп Дат
а
Збої.
Незвичайний трафік, що надходить з однієї чи невеликої
групи IP-адрес.
Сплеск трафіку від користувачів із загальним профілем
(модель системи, геолокація, версія веб-браузера тощо).
Пам’ятайте, що не всі DDoS-атаки мають великий трафік.
Невелика атака з короткою тривалістю часто залишається поза
увагою як випадкова подія. Однак ці атаки можуть бути тестом або
відволіканням для більш небезпечного порушення (наприклад,
програми-вимагача). Тому виявлення невеликої атаки є таким же
життєво важливим, як і виявлення повномасштабного DDoS.
Розгляньте можливість організації навчальної програми безпеки,
яка навчатиме весь персонал ознакам DDoS-атаки. Таким чином,
вам не потрібно чекати, поки співробітник служби безпеки
помітить попереджувальні знаки.
e) Обмеження мережевого мовлення.
Хакер, який стоїть за DDoS-атакою, швидше за все, надсилатиме
запити на кожен пристрій у вашій мережі, щоб посилити вплив.
Команда безпеки може протидіяти цій тактиці, обмеживши
мережеве мовлення між пристроями.
Обмеження (або, якщо можливо, вимкнення) широкомовної
переадресації є ефективним способом перервати спробу DDoS у
великому обсязі. Там, де це можливо, необхідно надати
працівникам вказівки вимкнути відлуння та платні послуги.
Лист
ЧДТУ.22.21091.006 ПЗ
15
Зм Арк №Докум. Підп Дат
а
1.2.3. Аналіз методів захисту кінцевих пристроїв інфраструктури
Для забезпечення повної захищеності інфраструктури, необхідно
впроваджувати захист і до кінцевих пристроїв [4] в тому числі ПК
працівників.
Для забезпечення захищеності цих пристроїв необхідно впровадити
наступні методи захисту:
1) Шифрування носіїв інформації.
Даний метод допоможе захистити дані що знаходяться на носію
інформації, якщо зловмисник спробує їх скопіювати з пристрою. Для
реалізації даного методу можна використати форматування LUCKS.
2) Використання пропрієтарного програмного забезпечення.
Важливо користуватися лише перевіреним програмним
забезпеченням для зменшення ризику зараження робочого ПК
вірусами, що можуть скомпрометувати конфіденційні дані.
3) Регулярне оновлення системи.
Необхідно оновлювати систему, особливо встановлювати оновлення
системи безпеки, оскільки деякі атаки націлені на застрілі версії
програмного забезпечення для операційної системи.
4) Створення та зберігання резервних копій даних.
Для того щоб не втратити цінні дані, що зберігаються на ПК,
необхідно створювати резервні копії, та потрібно бути обережним й
тримати їх в захищеному місці.
1.3. Аналіз етапу підготовки працівників
Оскільки людські помилки відіграють ключову роль у 95% порушень
кібербезпеки, керування кіберризиками для співробітників має важливе
значення для вашого бізнесу, щоб уникнути витоку даних користувачів і
продемонструвати дотримання нормативних вимог.
Лист
ЧДТУ.22.21091.006 ПЗ
16
Зм Арк №Докум. Підп Дат
а
Одним з ключових компонентів сильної програми управління
людськими ризиками (HRM) є постійне навчання з питань безпеки, яке
навчає кінцевих користувачів тому, як виявляти сучасні загрози та боротися
з ними, а також передовим практикам, щоб залишатися підкованими в
безпеці.
Але прийняття рішення про запуск такого типу навчання пов’язане з
деякими поширеними запитаннями, не в останню чергу з яких варто
вибрати теми навчання з питань безпеки, які необхідно включити.
Нижче проведено аналіз та сформовано список тем, котрі слід
включити до основної навчальної програми з питань безпеки для
працівників підприємства для забезпечення.
1.3.1. Аналіз основних тем для навчальної програми працівників
До основних тем для навчальної програми працівників [5] можна
віднести наступні:
1) Спеціалізований курс по попередженню та ліквідації вразливостей,
орієнтований на конкретну технологію.
Так як процес розробки може бути інтенсивним, то важливо
забезпечити працівників всіма необхідними знаннями для
забезпечення надійного захисту створюваного продукту, поступове
впровадження такої освіти дасть можливість працівникам
покращувати захищеність додатку без накопичування великої
кількості вразливостей.
Дана тема є основною темою з підготовки розробників по
запобіганню хакерським атакам та вивченню найкращих практик з
забезпечення інформаційної безпеки, що застосовуються для
технології з якою працює команда розробників.
2) Фішингові атаки.
Лист
ЧДТУ.22.21091.006 ПЗ
17
Зм Арк №Докум. Підп Дат
а
Фішинг залишається одним із найефективніших способів атаки для
кіберзлочинців. Подвоївшись у 2020 році, кількість фішингових атак
неухильно зростала протягом 2021 року, а через віддалену роботу
компаніям було складніше гарантувати, що їхні користувачі не
стануть жертвами. Але чому фішинг все ще є такою загрозою для
бізнесу зараз? Одним з основних факторів є те, наскільки
витонченими стали ці типи атак. Тепер зловмисники використовують
розумніші методи, щоб обманом змусити співробітників зламати
конфіденційні дані або завантажити шкідливі вкладення. Наприклад,
компрометація бізнес-електронної пошти (BEC) — це поширена
форма фішингу, яка використовує попередні дослідження конкретної
особи — наприклад, керівника компанії — для створення атаки, яку
надзвичайно важко відрізнити від справжньої електронної пошти.
Поєднайте ці розумніші атаки з поширеною помилкою про те, що
фішинг «легко помітити», і тоді не дивно, чому, за прогнозами,
Співробітники потребують регулярного навчання тому, як
розпізнавати фішингові атаки, які використовують сучасні методи, а
також як повідомляти про фішингові атаки, як тільки вони вважають,
що вони стали ціллю.
3) Змінні носії.
Ще одна тема безпеки, яку щодня використовують компанії, – це
знімні носії. Змінний носій — це портативний носій, який дозволяє
користувачам копіювати дані на пристрій, а потім видаляти їх із
пристрою на інший і навпаки. USB-пристрої, які містять зловмисне
програмне забезпечення, можна залишити для пошуку кінцевими
користувачами, коли вони підключать їх до свого пристрою.
«Дослідники впустили майже 300 USB-накопичувачів на кампус
Університету Іллінойсу в Урбана-Шампейн. 98% цих дисків було
Лист
ЧДТУ.22.21091.006 ПЗ
18
Зм Арк №Докум. Підп Дат
а
підібрано! Крім того, 45% цих дисків було не тільки підібрано, люди
навіть намагалися відкрити файли, що вони знайшли всередині»
Окрім розуміння ризиків, ваші працівники повинні знати, як безпечно
та відповідально використовувати ці пристрої у вашому бізнесі. Є
багато причин, чому компанія вирішила б використовувати знімні
носії у своєму середовищі. Проте з усіма технологіями завжди
існуватимуть потенційні ризики. Як і самі пристрої, важливо, щоб
ваші співробітники захищали дані на цих пристроях. Незалежно від
того, особисті чи корпоративні, усі дані мають певну цінність.
Кілька типових прикладів знімних носіїв, які ви та ваші співробітники
можете використовувати на робочому місці:
USB-накопичувачі
SD карти компакт-диски
Смартфони
Цю тему щодо поінформованості про безпеку слід включити до
вашого навчання та охоплювати приклади знімних носіїв, чому вони
використовуються в бізнесі, а також як ваші співробітники можуть
запобігти таким ризикам, як втрата чи викрадення знімних пристроїв,
зараження зловмисним програмним забезпеченням і порушення
авторських прав.
4) Паролі та автентифікація.
Дуже простий, але часто забутий елемент, який може допомогти у
безпеці вашої компанії, – це захист паролем. Зловмисники вгадують
часто використовувані паролі в надії отримати доступ до ваших
облікових записів. Використання простих паролів або використання
розпізнаваних шаблонів паролів для співробітників може спростити
доступ кіберзлочинців до великої кількості облікових записів. Після
викрадення цієї інформації її можна оприлюднити або продати з
метою отримання прибутку в глибокій мережі.
Лист
ЧДТУ.22.21091.006 ПЗ
19
Зм Арк №Докум. Підп Дат
а
Застосування випадкових паролів може значно ускладнити
зловмисникам доступ до ряду облікових записів. Інші кроки, такі як
двофакторна автентифікація, забезпечують додаткові рівні безпеки,
які захищають цілісність облікового запису.
5) Фізична безпека.
Якщо ви належите до тих людей, які залишають свої паролі на
наліпках на столі, ви можете викинути їх. Хоча багато атак, імовірно,
відбуваються через цифрові носії, захист конфіденційних фізичних
документів є життєво важливим для цілісності системи безпеки вашої
компанії.
Просте усвідомлення ризиків, пов’язаних із залишенням документів,
комп’ютерів без нагляду та паролів в офісі чи вдома, може зменшити
ризик безпеки. Впроваджуючи політику «чистого столу», загроза
викрадення або копіювання документів без нагляду може бути значно
зменшена.
6) Безпека мобільного пристрою.
Змінний ландшафт ІТ-технологій покращив здатність до гнучких
робочих середовищ, а разом з цим і до більш складних атак безпеки.
Оскільки тепер багато людей мають можливість працювати в дорозі
за допомогою мобільних пристроїв, розширення можливостей
підключення супроводжується ризиком порушень безпеки. Для
невеликих компаній це може бути ефективним способом економії
бюджету, однак на зараз підзвітність користувачам-пристроям стає
все більш актуальним аспектом навчання, особливо для працівників,
які подорожують або віддалених працівників. Поява шкідливих
програм для мобільних пристроїв збільшила ризик того, що мобільні
телефони містять зловмисне програмне забезпечення, яке потенційно
може призвести до порушення безпеки.
Лист
ЧДТУ.22.21091.006 ПЗ
20
Зм Арк №Докум. Підп Дат
а
Онлайн-курси передового досвіду для працівників мобільних
пристроїв можуть допомогти навчити співробітників уникати ризиків
без використання дорогих протоколів безпеки. Мобільні пристрої
завжди повинні мати конфіденційну інформацію, захищену паролем,
зашифровану або з біометричною автентифікацією на випадок втрати
або викрадення пристрою. Безпечне користування персональними
пристроями є необхідним навчанням для всіх працівників, які
працюють на власних пристроях.
Найкраща практика спільноти полягає в тому, щоб переконатися, що
працівники повинні підписати політику мобільної безпеки.
7) Віддалена робота.
У 2021 році очевидна потреба у віддаленій роботі в поєднанні зі
зростаючим попитом призвела до того, що багато компаній вжили
рішучих кроків у напрямку політики повної роботи з дому. Віддалена
робота може бути позитивною для компаній і розширювати
можливості для працівників, сприяючи підвищенню продуктивності
та більшому балансу між роботою та особистим життям. Однак ця
тенденція створює підвищену загрозу для порушень безпеки, якщо не
безпечно проінформовано про ризики віддаленої роботи. Особисті
пристрої, які використовуються для роботи, повинні залишатися
заблокованими без нагляду та мати встановлене антивірусне
програмне забезпечення. Якщо компанія хоче запропонувати такий
стимул, вона повинна зосередитися на навчанні віддалених
працівників безпечним методам роботи.
Ті, хто адаптувався до стилю життя WFH, можливо, віддадуть
перевагу працювати таким чином. Необхідність навчити працівників
розуміти власну кібербезпеку та керувати нею є очевидною. Як
бачимо, загрози, націлені на цих осіб, зростають.
8) Публічний Wi-Fi.
Лист
ЧДТУ.22.21091.006 ПЗ
21
Зм Арк №Докум. Підп Дат
а
Деяким працівникам, яким потрібно працювати віддалено,
подорожувати потягами чи працювати в дорозі, можливо,
знадобиться додаткове навчання, щоб зрозуміти, як безпечно
користуватися громадськими службами Wi-Fi. Фальшиві
загальнодоступні мережі Wi-Fi, які в кав’ярнях часто видають за
безкоштовний Wi-Fi, можуть зробити кінцевих користувачів
уразливими до введення інформації на незахищені публічні сервери.
Навчання користувачів безпечному користуванню
загальнодоступною Wi-Fi і загальним ознакам виявлення
потенційного шахрайства підвищить обізнаність компаній і мінімізує
ризик.
9) Хмарна безпека.
Хмарні обчислення революціонізували бізнес, спосіб зберігання та
доступу до даних. Ці цифрові додатки трансформують бізнес, однак,
оскільки велика кількість особистих даних зберігається віддалено,
виникає ризик великомасштабного злому. Багато великих компаній
працюють над захистом даних, але якщо правильно вибрати
постачальника хмарних послуг, хмарне сховище може стати набагато
безпечнішим і економічно ефективнішим способом зберігання даних
вашої компанії.
Як і в інших згаданих темах, інсайдерський злом становить набагато
більшу загрозу, ніж для великих хмарних компаній. Деякі видання
прогнозують, що до наступного року 99% усіх інцидентів із хмарною
безпекою відбуватимуться з вини кінцевого користувача. Таким
чином, навчання з кібербезпеки може допомогти співробітникам
безпечно використовувати хмарні програми.
10) Використання соціальних мереж.
Ми всі ділимося значною частиною свого життя в соціальних
мережах: від свят до подій і роботи. Але надмірний обмін може
Лист
ЧДТУ.22.21091.006 ПЗ
22
Зм Арк №Докум. Підп Дат
а
призвести до того, що конфіденційна інформація стане доступною,
що дозволить зловмиснику легко видати себе за надійне джерело
(див.: соціальна інженерія).
Навчання співробітників щодо захисту налаштувань
конфіденційності їхніх облікових записів у соціальних мережах і
запобігання поширенню загальнодоступної інформації вашої
компанії зменшить ризик потенційного впливу, який хакери можуть
отримати від такого доступу до вашої особистої мережі.
11) Використання Інтернету та електронної пошти.
Деякі співробітники, можливо, вже зазнали витоку даних через
використання простих або повторних електронних листів для кількох
облікових записів. Одне дослідження показало, що 59% кінцевих
користувачів використовують той самий пароль для кожного
облікового запису. Це означає, що якщо один обліковий запис
зламано, хакер може використати цей пароль у робочих облікових
записах і облікових записах соціальних мереж, щоб отримати доступ
до всієї інформації користувача в цих облікових записах.
Часто веб-сайти пропонують безкоштовне програмне забезпечення,
заражене зловмисним програмним забезпеченням, завантажені
програми лише з перевірених джерел є найкращим способом
захистити ваш комп’ютер від встановлення шкідливого програмного
забезпечення.
Навчання співробітників безпечним звичкам в Інтернеті має бути
ключовою частиною будь-якого введення в ІТ, хоча деякі можуть
вважати це навчання очевидним, це ключова частина безпеки будь-
якої програми безпеки. Останніми роками багато великих веб-сайтів
мали серйозні витоки даних. Якщо вашу інформацію було введено на
ці сайти, вона могла стати загальнодоступною та розкрити вашу
особисту інформацію.
Лист
ЧДТУ.22.21091.006 ПЗ
23
Зм Арк №Докум. Підп Дат
а
12) Соціальна інженерія.
Соціальна інженерія — це поширена техніка, яку використовують
зловмисники, щоб завоювати довіру співробітників, пропонуючи
цінні приманки або видаючи себе за іншу особу, щоб отримати доступ
до цінної особистої інформації. Щоб протистояти цим загрозам,
співробітники мають бути навчені темам безпеки, які охоплюють
найпоширеніші методи соціальної інженерії та психологію впливу
(наприклад: дефіцит, терміновість і взаємність).
Наприклад, видаючи себе за життєздатного клієнта або пропонуючи
стимули, особиста інформація може бути мимоволі передана цим
зловмисникам. Підвищення рівня обізнаності працівників щодо
загрози, пов’язаної з цим виданням, має вирішальне значення для
зниження ризику соціальної інженерії.
1.4. Висновки до розділу
В даному розділі були проаналізовані методи захисту, що мають
застосовуватися на етапі підготовки до безпосередньої розробки веб-
додатку.
В результаті аналізу можна стверджувати що розглянуті методи
можуть бути задіяні як комплекс / система методів оскільки наведені
методи не є взаємовиключними, а є взаємодоповнюючими.
Для зменшення витрат на впровадження комплексу методів, компанія
може розглянути можливість відмови від захисту певного сегменту,
наприклад, зменшити витрати на системи безпеки серверної кімнати й
перенести сервери в захищений дата-центр. Компанія має сама обрати для
себе стратегію захисту на основі наданого аналізу.
Лист
ЧДТУ.22.21091.006 ПЗ
24
Зм Арк №Докум. Підп Дат
а
РОЗДІЛ 2: АНАЛІЗ МЕТОДІВ ЗАХИСТУ, ЩО
ВПРОВАДЖУЮТЬСЯ ТА ЗАСТОСОВУЮТЬСЯ НА ЕТАПІ
РОЗРОБКИ ВЕБ-ДОДАТКУ
Розробка веб-додатку полягає у поетапній реалізації вимог
замовника, що формуються в завдання. Цикл розробки (Рисунок 2.1)
включає в себе декілька етапів, через які проходить кожне завдання.
Завдання вважатиметься завершеним коли воно успішно пройде останній
етап.
Цикл розробки
1 Формування завдання
2 Реалізація
Перевірка коду
3
Code review Аналізатори коду
ТЕСТУВАННЯ
Автоматизоване
4 [юніт | інтеграційне | функціональне]
Ручне
Рисунок 2.1 - Схема циклу розробки.
Лист
ЧДТУ.22.21091.006 ПЗ
25
Зм Арк №Докум. Підп Дат
а
Цикли розробки можуть дещо відрізнятися від наведеного в
залежності від архітектури проекту та сформованого протоколу розробки.
Методи захисту, що впроваджуються на етапі розробки можуть бути
поділені на наступні категорії:
Методи автентифікації та авторизації - методи, що застосовуються в
процесі розробки для формування ядра системи керування
привілеями;
Загальні методи виявлення вразливостей - методи, що застосовуються
в процесі розробки для виявлення різних вразливостей в додатку.
Загальні методи попередження/ліквідації вразливостей - методи що
використовуються в процесі розробки для ліквідації низки
вразливостей;
Спеціалізовані методи захисту - це методи що використовуються в
процесі розробки для підвищення захисту проти конкретного типу
атак.
2.1. Аналіз методів автентифікації та авторизації
При розробці захищеного додатку першим кроком для захисту є
реалізація методу входу в систему (ідентифікація та автентифікація) та
системи перевірки прав користувачів (авторизація).
2.1.1. Аналіз методу автентифікації на основі форм
Для даного методу немає певного стандарту, тому всі його реалізації
специфічні для кожної системи, а саме, для компонентів автентифікації
фреймворків розробки. Працює ця схема, як показано далі: HTML-форма
додається до веб-додатку, в неї користувач повинен ввести свої дані (ім’я /
пароль) і відправити на сервер через HTTP методом POST для
автентифікації. Після отримання відповіді сервера з кодом успіху, додаток
створює токен сесії, який, здебільшого, поміщається в файл cookie. При
Лист
ЧДТУ.22.21091.006 ПЗ
26
Зм Арк №Докум. Підп Дат
а
наступних запитах токен сесії автоматично додається до заголовку запиту і
відправляється на сервер, що дозволяє отримувати інформацію про
поточного користувача через додаток для послідуючих авторизацій запитів
(Рисунок 2.2).
Рисунок 2.2. – Схема роботи автентифікації на основі форм.
Додаток здатен створити токен сесії двома способами:
У вигляді унікального ідентифікатору (UUID) автентифікованої сесії
користувача, вона зберігається в базі даних або пам’яті сервера. Сесія
повинна містити всю необхідну інформацію про користувача для
авторизації його запитів.
У вигляді підписаного та / або зашифрованого об'єкту, котрий містить
дані про користувача, а також - термін життя (TTL). Цей спосіб
дозволяє реалізувати “вільну від стану” архітектуру сервера, але
потребує механізму оновлення ідентифікатора сесії після того, як
його термін життя добіжить кінця.
Лист
ЧДТУ.22.21091.006 ПЗ
27
Зм Арк №Докум. Підп Дат
а
Необхідно тримати в голові, що викрадення ідентифікатора сесії в
системах без стану, дає аналогічний рівень доступу, як і знання паролю та
логіну. Тому все «спілкування» між клієнтом та сервером повинно
відбуватися за допомогою захищеного протоколу HTTPS.
2.1.2. Аналіз методу автентифікації по сертифікату
Сертифікат являє собою набір атрибутів, котрі ідентифікують
власника (сервіс), сертифікати підписуються Центром Сертифікації (CA).
CA є посередником, що повинен гарантувати справжність сертифікатів.
Сертифікат пов'язаний з закритим ключем, шляхом застосування
криптографічних методів, закритий ключ, зазвичай, зберігається у власника
сертифіката.
Закритий ключ та сам сертифікат на стороні клієнта можуть
зберігатися в в операційній системі, браузері, в файлі, на окремому
фізичному пристрої (smart card). Закритий ключ зазвичай захищають PIN-
кодом або паролем.
Як правило у веб-додатках використовуються сертифікати стандарту
X.509, котрий визначає формати даних та процедури розподілу відкритих
ключів через сертифікати з цифровими підписами. Автентифікація на базі
сертифіката X.509 відбувається під час з'єднання з сервером, вона є
частиною протоколів SSL / TLS.
Лист
ЧДТУ.22.21091.006 ПЗ
28
Зм Арк №Докум. Підп Дат
а
Наразі цей механізм без проблем підтримується більшістю
браузерами, котрі дозволяють користувачу обирати і застосувати
сертифікат [6], в тих випадках, коли у веб-сайту передбачено такий спосіб
автентифікації (Рисунок 2.3).
Рисунок 2.3 – Схема роботи автентифікації на основі сертифікату.
Під час автентифікації сервер перевіряє сертифікат на предмет
виконання наступних правил:
сертифікат має бути дійсним на поточну дату;
Лист
ЧДТУ.22.21091.006 ПЗ
29
Зм Арк №Докум. Підп Дат
а
Центр сертифікації, що підписав сертифікат повинен бути довіреним
(перевірка ланцюжка сертифікатів);
Сертифікат має бути не відкликаним відповідним CA [6] (перевірка
списків виключення) (Рисунок 2.4).
Рисунок 2.4 – Приклад сертифікату.
Після автентифікації веб-додаток спробує авторизувати запит на
основі наступних даних сертифіката: subject (ім'я власника), issuer (емітент),
thumbprint (відбиток відкритого ключа сертифіката) або серійний номер
сертифікату.
Використовувати сертифікати для автентифікації є більш надійним
способом, ніж автентифікація на основі паролів, оскільки в процесі
автентифікації відбувається створення цифрового підпису, що підтверджує
факт використання закритого ключа в певних ситуаціях (non-repudiation).
Лист
ЧДТУ.22.21091.006 ПЗ
30
Зм Арк №Докум. Підп Дат
а
Але підтримка і поширення сертифікатів мають певні труднощі, що робить
даний спосіб автентифікації малодоступним.
2.1.3. Аналіз методу автентифікації на основі одноразових
паролів
Автентифікація на основі одноразових паролів застосовується, як
додаток до автентифікації на основі паролів для реалізації двох-факторної
автентифікаці (two-factor authentication). У даному мутоді користувач
повинен надати дані двох типів для входу в систему, наприклад: щось, чим
володіє (пристрій генерації одноразових паролів), та щось, що він знає
(пароль). Наявність цих двох факторів в значній мірі підвищує рівень
безпеки, така схема часто є затребуваною для певних видів веб-додатків.
Одним з популярних способів використання одноразових паролів
може бути додатковою автентифікацією користувача під час виконання
певних важливих дій: зміна налаштувань, переказ грошей і т. п.
Існують різні способи створення одноразових паролів. Найбільш
популярні наведено нижче.
Програмні або апаратні маркери, котрі генерують одноразові паролі
на основі секрету, який в них вводиться, і, наприклад, поточного
часу. Секретні ключі користувачів є підтвердженням факту
володіння, вони зберігаються на сервері, що дає можливість
перевіряти введені одноразові паролі. Прикладом програмної
реалізації такого підходу є додаток Google Authenticator.
Коди, котрі передаються користувачеві через SMS чи інші канали
зв'язку є насправді випадковими. У цій ситуації фактором володіння
буде телефон користувача (а точніше - SIM-карта, яка прив'язується
до певного номера).
Лист
ЧДТУ.22.21091.006 ПЗ
31
Зм Арк №Докум. Підп Дат
а
Scratch card або роздруківка що містить список заздалегідь
сформованих одноразових паролів. При кожному повторному вході в
систему необхідно вводити новий одноразовий пароль.
Часто механізми автентифікації у веб-додатках реалізуються за
рахунок розширення автентифікації по формах, наприклад, сесія
користувача може створюватися після первинної автентифікації по паролю,
але користувач все ще не матиме доступ до додатку, в контексті даної сесії,
поки він не виконає умови додаткової автентифікації, і не надасть
одноразовий пароль.
2.1.4. Аналіз методу автентифікації на основі ключів доступу
Метод використовується при запитах до інших веб-сервісів, для
автентифікації таких сервісів, пристроїв або інших веб-додатків. В якості
секретного ключа, використовуються ключі доступу (access key, API key) -
унікальні довгі рядки, що містять набір випадкових символів, котрі
замінюють собою комбінацію логін / пароль.
Для початку, сервер генерує ключі доступу після обробки запиту
користувача, а далі зберігає надані ключі в додатках клієнту. Для таких
ключів доступу можна вказувати термін життя і рівень доступу, які отримає
клієнтська програма при автентифікації на основі такого ключа ключа.
Гарним прикладом такого методу є хмара Amazon Web Services.
Припустимо, що користувач має веб-додаток, котрий дозволяє переглядати
і завантажувати фото, для зберігання файлів, він хоче використати сервіс
Amazon S3. В такому випадку, користувач може створити ключ, через
консоль AWS, такий ключ має обмежений доступ до хмари (тільки читання
та запис файлів в Amazon S3).
Лист
ЧДТУ.22.21091.006 ПЗ
32
Зм Арк №Докум. Підп Дат
а
Такий ключ необхідно буде застосувати для виконання
автентифікації веб-додатку в хмарному сервісі AWS (Рисунок 2.5).
Рисунок 2.5 – Схема роботи автентифікації по ключах доступу.
Використання таких ключів надає можливість уникати передачі
пароля користувача стороннім додаткам. Ключі мають куди більшу
ентропію в порівнянні з паролями, саме тому їх майже неможливо
підібрати. І навіть, якщо ключ був розкритий, то це не скомпрометує
основного облікового запису користувача, адже ми можемо просто
анулювати даний ключ і просто створити новий.
Для даного методу не існує єдиного підходу, з технічної точки зору
ключі можуть передаватися в різних частинах HTTP-запиту: тіло запиту,
адресний рядок, або заголовок HTTP. Найбільш захищений варіант, як і з
використанням автентифікації на основі паролю, - використання заголовку
HTTP. У деяких випадках використовується HTTP-схема Bearer для
Лист
ЧДТУ.22.21091.006 ПЗ
33
Зм Арк №Докум. Підп Дат
а
відправки токена в заголовку (Authorization: Bearer [token]). З'єднання з
сервером повинне бути захищене протоколом SSL / TLS (не нижче версії
1.2), щоб уникнути перехоплення ключа.(Рисунок 2.6).
Рисунок 2.6 – HTTP-схема Bearer.
Крім того, існують більш складні методи автентифікації на основі
ключів для незахищених з'єднань. В яких, ключ складається з двох
складових: таємної та публічної. Таємна частина дає можливість
згенерувати підпис, а публічна - використовується в процесі ідентифікації
клієнта. Для прикладу, використаємо аналогію зі схемою цифрової
автентифікації, сервер надсилає клієнту унікальне значення часову мітку,
або nonce, а клієнт - повертає HMAC наданого значення або хеш, що
вирахуваний на основі секретної частини ключа. Це дасть можливість
уникнути передачі всього ключа в його оригінальному вигляді і захистить
від атак на повторення.
2.1.5. Аналіз методу автентифікації на основі токенів
Цей метод автентифікації здебілього застосовується для реалізації
розподілених систем (Single Sign-On (SSO)), де один додаток (relying party
чи service provider) перенаправляє автентифікацію користувачів іншому
додатку (authentication service / identity provider). Типовим прикладом
даного методу є вхід в систему через обліковий запис в соц. мережах. В
наведеному прикладі соціальні мережі є сервісами автентифікації, а додаток
лише делегує функцію автентифікації цим сервісам автентифікації.
Лист
ЧДТУ.22.21091.006 ПЗ
34
Зм Арк №Докум. Підп Дат
а
Реалізація цього методу полягає в наступному: провайдер
ідентифікації (IP) надає достовірну інформацію про користувача у вигляді
токена, провайдер послуг (SP), в свою чергу, це додаток що використовує
наданий токен для автентифікації та авторизації користувача.
Даний процес виглядає виконується таким чином:
клієнт автентифікується через провайдера ідентифікації одним із
запропонованих способів (ключ доступу, пароль, Kerberos,
сертифікат, ітд.);
клієнт запрошує у провайдера ідентифікації токен для провайдера
послуг додатку. Провайдер ідентифікації, в свою чергу, відправляє
клієнту згенерований токен;
клієнт автентифікується через провайдера послуг, за допомогою
наданого токена (Рисунок 2.7);
Рисунок 2.7 – Схема автентифікації по токенах активного клієнта.
Описаний вище процес відображає алгоритм автентифікації
активного клієнта, тобто такого, який має здатність виконувати певну
запрограмовану послідовність дій (Android / iOS програми). Натомість,
браузер є пасивним клієнтом, оскільки він лише може відображати
Лист
ЧДТУ.22.21091.006 ПЗ
35
Зм Арк №Докум. Підп Дат
а
сторінки, котрі запитує користувач. В таких випадках автентифікація
досягається за рахунок автоматичного перенаправлення користувача між
веб-додатками провайдера послуг та провайдера ідентифікації (Рисунок
2.8).
Рисунок 2.8 – Схема автентифікації по токенах пасивного клієнта.
Існує кілька стандартів, які в визначають протоколи взаємодії між
активними / пасивними клієнтами і SP / IP-додатками, а також формати
підтримуваних токенів. Серед найпопулярніших стандартів є: SAML,
OAuth, OpenID Connect і WS-Federation. Деяка інформація про ці протоколи
- нижче в статті.
2.2. Аналіз загальних методів виявлення вразливостей.
Після визначення алгоритмів, що будуть використані для керування
входом в систему та перевіркою прав, наступним кроком є впровадження
методів, що підвищують загальний рівень захисту системи.
Нижче наведено аналіз загальних методів виявлення вразливостей в
додатках, аналіз проведено на предмет наступних характеристик: сценарії
застосування, принцип дії, переваги та недоліки.
Лист
ЧДТУ.22.21091.006 ПЗ
36
Зм Арк №Докум. Підп Дат
а
2.2.1. Аналіз методу впровадження аудиту та журналювання.
Сценарії застосування: необхідно використовувати завжди
незалежно від архітектури.
Принцип дії: аудит фіксує зміни в даних, а саме ким і коли ці зміни
були зроблені, створюючи історію змін, журналювання (logging)
реалізується шляхом впровадження логерів у відповідних місцях коду, коли
процес заходить у відповідну гілку, логер записує деталі процесу, що
відбуваються на сервері, в журнал подій.
Переваги: більша частина цього функціоналу вбудована в
обслуговуюче програмне забезпечення, наприклад IIS (Internet Information
Services), і є легкодоступним, якщо вам знадобиться переглянути різну
інформацію, пов’язану з діяльністю. Журнали не тільки часто є єдиним
записом про підозрілу діяльність, але й забезпечують індивідуальну
підзвітність, відстежуючи дії користувача. На відміну від ведення журналу
помилок, ведення журналу активності чи аудиту взагалі не потребує багато
налаштувань, оскільки воно зазвичай вбудоване у програмне забезпечення
веб-сервера. Обов’язково використовуйте його для виявлення небажаних
дій, відстеження дій кінцевого користувача та перегляду помилок
програми, які не виявляються на рівні коду. У вкрай рідкісних випадках
журнали можуть знадобитися в судових процесах. У цих випадках обробка
даних журналу є критичною.
Недоліки: потребує постійної підтримки та актуалізації.
2.2.2. Аналіз методу ретельного контролю якості та тестування
на проникнення
Сценарії застосування: необхідно використовувати завжди
незалежно від архітектури.
Принцип дії: тестування здебільшого має декілька рівнів:
Лист
ЧДТУ.22.21091.006 ПЗ
37
Зм Арк №Докум. Підп Дат
а
юніт тестування зосереджене на тестуванні обмеженої та ізольованої
логіки;
інтеграційне тестування застосовується коли необхідно протестувати
декілька рівнів додатку та їхню взаємодію між собою;
Функціональне тестування - це комплексне автоматизоване
тестування, яке націлене на тестування всієї системи;
Ручне тестування, є окремим видом тестування, оскільки
застосовується як останній етап у тестуванні роботи додатку,
націлене змоделювати якомога більше ймовірних ситуацій яку
можуть виникнути при реальній роботі додатку.
Даний етап дозволяє виявляти помилки, допущені в процесі
написання коду. З точки зору безпеки для тестування на проникнення
компанія може найняти профільного тестувальника, що спеціалізується на
безпеці або підготувати вже наявну команду тестувальників, для тестування
на предмет базових вразливостей, якщо ж проект потребує високого рівня
захисту то команда спеціалістів з безпеки вже буде необхідністю, а не
рекомендацією.
Переваги: завдяки багаторівневій структурі даний етап дозволяє
зменшити кількість можливих вразливостей та недоліків програми до
мінімуму.
Недоліки: даний етап сумарно займає значну частину ресурсів та
часу розробки.
Лист
ЧДТУ.22.21091.006 ПЗ
38
Зм Арк №Докум. Підп Дат
а
2.2.3. Аналіз методу впровадження статичних аналізаторів коду
Сценарії застосування: аналізатори впроваджуються на платформах
для розробки таких як GitHub чи GitLab як частина ланцюжка пайплайнів
та застосовуються на етапі перевірки коду коли розробник відправляє новий
код на платформу. Застосовуються на етапі перевірки коду.
Принцип дії: назва “статичний аналізатор коду” говорить сама за
себе, ці інструменти “переглядають” код та аналізують його на предмет
наявних шаблонів вразливостей, ці інструменти вміють навіть навігуватися
по ланцюгу виклику методів/функцій.
Переваги: аналізатори коду можуть виявляти величезну кількість
вразливостей в коді і їх легко інтегрувати в проект незалежно від того на
якому етапі розробки він знаходиться.
Недоліки: більшість з них є платними, окрім цього, так як вони не
здатні розпізнати абсолютно всі технології, що застосовуються на проекті,
вони часто можуть вказувати на вразливість якої не існує, всі подібні
потенційні вразливості потребуватимуть часу та уваги розробників для того
щоб дійсно підтвердити що вразливостей у вказаному місці нема, зокрема
навіть якщо вказати аналізатору, що дане місце не є вразливим, при
подальших змінах в коді ці місця будуть помічатися як вразливі знову і
знову. Тому аналізатори підійдуть далеко не для кожного веб-проекту, а
лише для тих які потребують високий або вкрай високий рівень
захищеності, або для проектів на яких інтенсивність розробки є невисокою.
Лист
ЧДТУ.22.21091.006 ПЗ
39
Зм Арк №Докум. Підп Дат
а
Приклад: Checkmarx CxSAST, Mend (Рисунок 2.9), SonarQube,
Veracode, Fortify Static Code Analyser, Codacy, AppScan.
Рисунок 2.9 – результат сканування проектів за допомогою аналізатора
Mend.
2.3. Аналіз загальних методів попередження/ліквідації
вразливостей
Нижче наведено аналіз загальних методів попередження/ліквідації
вразливостей в додатках, аналогічно до попереднього пункту аналіз
проведено на предмет: сценаріїв застосування, принципу дії, переваг та
недоліків.
2.3.1. Аналіз методу регулярних оновлень бібліотек та інших
залежностей проекту
Сценарії застосування: необхідно використовувати завжди
незалежно від архітектури.
Принцип дії: метод базується на тому, що з часом в сторонньому
забезпеченні (бібліотеках та інших залежностях що підключені до проекту)
знаходять вразливості і цими вразливостями можуть скористуватися
Лист
ЧДТУ.22.21091.006 ПЗ
40
Зм Арк №Докум. Підп Дат
а
хакери, тому необхідно слідкувати за оновленнями бібліотек, і
використовувати їх останні стабільні версії.
Переваги: зниження ймовірності використання старих вразливостей,
що були присутні в використовуваних бібліотеках. Завдяки оновленню,
можна використовувати останні нові можливості підключених бібліотек.
Недоліки: деякі бібліотеки перестають підтримуватися, і єдиним
варіантом залишається заміна такої “мертвої” бібліотеки на актуальний
аналог. Також, оновлення бібліотек може бути дуже дорогим в плані часу
розробки і потребуватиме великих змін на проекті, а відповідно і дуже
ретельного тестування.
2.3.2. Аналіз методу обробки вхідних даних
Сценарії застосування: необхідно використовувати завжди
незалежно від архітектури.
Принцип дії: метод полягає у впровадженні жорстких правил
прийому та перевірки вхідних даних, а саме, приймати необхідно лише
потрібні дані потрібного типу і не більше, ці дані потребують необхідної
перевірки. Якщо необхідно прийняти широкий спектр даних, то необхідно
застосовувати ретельну перевірку на предмет наявності лише дозволених
символів, розміру, шаблону (наприклад для email). Даний метод є кроком
до впровадження більш правильної архітектури.
Переваги: може бути частиною бізнес-логіки додатку, є простим у
впровадженні, та може бути використаний в комплексі з іншими методами
захисту.
Недоліки: потребує постійної підтримки актуальності коду, та
потребує ретельного тестування.
Приклад:
Лист
ЧДТУ.22.21091.006 ПЗ
41
Зм Арк №Докум. Підп Дат
а
для правильного прийому таких даних як email, можна
використовувати обмеження по довжині та регулярний вираз
(Рисунок 2.10) для перевірки шаблону.
Рисунок 2.10 – Регулярний вираз для перевірки email.
якщо необхідно отримати ресурс за ідентифікатором, то API повинне
отримувати лише числовий ідентифікатор.
2.3.3. Аналіз методу впровадження протоколу SSL/TLS
Сценарії застосування: необхідно використовувати завжди
незалежно від архітектури.
Принцип дії: на відміну від старого методу передачі даних у якому
дані передавались у вигляді відкритого тексту, який будь-хто міг прочитати,
якщо перехопив повідомлення. Наприклад, якщо споживач відвідав
торговий веб-сайт, зробив замовлення та ввів номер своєї кредитної картки
на веб-сайті, цей номер кредитної картки поширювався б Інтернетом
неприхованим. SSL було створено для вирішення цієї проблеми та захисту
конфіденційності користувачів. Шляхом шифрування будь-яких даних, які
передаються між користувачем і веб-сервером, SSL гарантує, що будь-хто,
хто перехопить дані, зможе побачити лише зашифрований безлад символів.
Номер кредитної картки споживача тепер у безпеці, видимий лише для
торгового веб-сайту, де він ввів його. SSL зупиняє певні види кібератак: він
Лист
ЧДТУ.22.21091.006 ПЗ
42
Зм Арк №Докум. Підп Дат
а
автентифікує веб-сервери, що важливо, оскільки зловмисники часто
намагаються створити підроблені веб-сайти, щоб обдурити користувачів і
викрасти дані. Це також запобігає фальсифікації зловмисниками даних під
час передачі, подібно до захищеної пломби на контейнері для ліків.
2.4. Аналіз спеціалізованих методів захисту
Спеціалізовані методи захисту використовуються для протидії
конкретному типу атак. Для даних методів застосуймо відповідне
групування по атаках, яким вони протидіють.
2.4.1. Аналіз методів протидії SQL-ін’єкціям
SQL-ін’єкція [7] – це тип ін’єкційної атаки. Ін’єкційні атаки
відбуваються, коли зловмисник надсилає зловмисно створені вхідні дані,
що змушує програму виконувати ненавмисну дію. Через повсюдне
поширення баз даних SQL впровадження SQL є одним із найпоширеніших
видів атак в Інтернеті.
Методи захисту:
1) Параметризовані запити (Prepared Statements) [8].
Сценарії застосування: є базовим методом захисту проти SQL
ін’єкцій, тому застосовується в більшості випадків.
Принцип дії: мови програмування спілкуються з базами даних SQL
за допомогою драйверів баз даних. Драйвер дозволяє програмі створювати
та запускати оператори SQL для бази даних, витягуючи та маніпулюючи
даними за потреби. Параметризовані оператори гарантують, що параметри
(тобто вхідні дані), передані в оператори SQL, обробляються безпечним
способом. Ви завжди повинні використовувати параметризовані оператори,
де вони доступні, вони є вашим захистом номер один від SQL ін’єкцій.
Переваги: є найбільш надійним методом захисту проти SQL ін’єкцій.
Лист
ЧДТУ.22.21091.006 ПЗ
43
Зм Арк №Докум. Підп Дат
а
Недоліки: іноді даний метод неможливо застосувати, наприклад, для
складних динамічних запитів, в разі, якщо технологія побудови таких
запитів застаріла і не може бути оновлена в короткі терміни, така ситуація
можлива на старих та дуже громіздких проектах з застарілою архітектурою.
Приклад: В наведеному нижче прикладі наявний запит будується
шляхом конкатенації рядків (Рисунок 2.11).
Рисунок 2.11 – Приклад вразливого до ін’єкцій коду.
Натомість, правильним варіантом (Рисунок 2.12) побудови запиту
має бути наступний:
Рисунок 2.12 – Приклад правильної побудови запиту до бази даних.
Лист
ЧДТУ.22.21091.006 ПЗ
44
Зм Арк №Докум. Підп Дат
а
2) Object Relational Mapping (ORM)
Сценарії використання: Багато команд розробників віддають
перевагу використанню інфраструктури Object Relational Mapping (ORM)
[9], щоб зробити перетворення наборів результатів SQL в об’єкти коду
більш плавним.
Принцип дії: інструменти ORM часто означають, що розробникам
рідко доведеться писати оператори SQL у своєму коді – і ці інструменти, на
щастя, використовують параметризовані оператори під капотом.
Найвідомішим ORM є, мабуть, фреймворк наразі є Active Record для Ruby
on Rails, також можна виділити Hibernate для Spring.
Переваги: інтуїтивно зрозумілий програмний інтерфейс та
інструменти, також ORM самостійно генерують запити до бази двних, і
використовують для цього параметризовані запити.
Недоліки: працює повільніше ніж вручну побудовані запити,
потребує значних змін в архітектурі додатку для впровадження.
Використання ORM не робить вас автоматично захищеними від SQL
ін’єкцій. Багато фреймворків ORM дозволяють створювати оператори SQL
або фрагменти операторів SQL, коли над базою даних потрібно виконати
більш складні операції. Наприклад наступний код з використанням Active
Record (Рисунок 2.13) є вразливим:
Рисунок 2.13 – Приклад вразливого коду з використанням ORM.
Лист
ЧДТУ.22.21091.006 ПЗ
45
Зм Арк №Докум. Підп Дат
а
Приклад: Нижче наведено приклад використання ORM Active
Record (Рисунок 2.14), інші ORM мають схожий принцип дії тож даний
приклад можна вважати універсальним.
Рисунок 2.14 – Приклад захищеного коду з використанням ORM.
3) Екранування символів
Сценарії використання: якщо ви не можете використовувати
параметризовані оператори або бібліотеку, яка пише SQL для вас,
наступним найкращим підходом є забезпечення належного екранування
спеціальних символів рядка у вхідних параметрах.
Принцип дії: ін’єкційні атаки часто покладаються на те, що
зловмисник зможе створити вхідні дані, які передчасно закриють рядок
аргументів, у якому вони з’являються в інструкції SQL. (Ось чому ми часто
бачимо символи ' або " під час спроб SQL-атаки.) У мовах програмування є
стандартні способи опису рядків, що містять лапки – SQL не відрізняється
в цьому відношенні. Як правило, подвоєння символу лапки – заміна ' на '' –
означає «розглядати цю лапку як частину рядка, а не як кінець рядка».
Екранування символів є простим способом захисту від більшості атак SQL-
ін’єкцій, і багато мов мають стандартні функції для досягнення цього.
Однак у цього підходу є кілька недоліків: Ви повинні бути дуже
обережними, щоб екранувати символи скрізь у вашій кодовій базі, де
створюється оператор SQL. Не всі ін’єкційні атаки покладаються на
зловживання символами лапок. Наприклад, коли в операторі SQL
очікується числовий ідентифікатор, лапки не потрібні.
Лист
ЧДТУ.22.21091.006 ПЗ
46
Зм Арк №Докум. Підп Дат
а
Переваги: даний метод може бути використаний практично в будь
якому випадку побудови запитів до бази.
Недоліки: для забезпечення надійного захисту необхідна доволі
складна та дуже продумана реалізація цього методу.
4) Перевірка та очищення вхідних даних
Сценарії застосування: може бути застосований практично в будь-
якому сценарію, також є гарною практикою застосовувати цей метод як
додатковий метод захисту.
Принцип дії: перевірка вхідних даних на предмет лише необхідних
символів, або на наявність підозрілих службових символів.
Переваги: є хорошою практикою для застосування даного методу, як
частини комплексного захисту.
Недоліки: не є абсолютним захистом проти SQL ін’єкцій, часто
валідація вмісту не може бути застосована до тих чи інших даних, оскільки
на вхід може вважатися легальним будь який рядок.
Приклад: користувач ввів наступний пароль ' or 1=1--, що виглядає
досить підозрілим для паролю. Розробники повинні завжди докладати
зусиль, щоб відхиляти вхідні дані, які виглядають підозрілими, пильнуючи,
щоб випадково не покарати звичайних користувачів. Наприклад, програма
може перевіряти параметри, надані в запитах GET і POST, такими
способами:
Переконайтеся, що надані поля, наприклад адреси електронної
пошти, відповідають регулярному виразу.
Переконайтеся, що цифрові або буквено-цифрові поля не містять
символів.
Відхиліть (або видаліть) пробіли та символи нового рядка, де вони
недоречні.
Перевірка на стороні клієнта (тобто в JavaScript) корисна для надання
користувачеві негайного відгуку під час заповнення форми, але не є
Лист
ЧДТУ.22.21091.006 ПЗ
47
Зм Арк №Докум. Підп Дат
а
захистом від серйозного хакера. Більшість спроб злому виконуються за
допомогою сценаріїв, а не самого браузера.
2.4.2. Аналіз методів захисту проти XSS атак
Cross-site scripting (також відомий як XSS [10]) — це вразливість веб-
безпеки, яка дозволяє зловмиснику скомпрометувати взаємодію
користувачів із уразливою програмою. Це дозволяє зловмиснику обійти ту
саму політику походження, яка розроблена для відокремлення різних веб-
сайтів один від одного. Уразливості міжсайтових сценаріїв зазвичай
дозволяють зловмиснику маскуватися під користувача-жертву, виконувати
будь-які дії, які користувач може виконати, і отримати доступ до будь-яких
даних користувача. Якщо користувач-жертва має привілейований доступ до
програми, зловмисник може отримати повний контроль над усіма
функціями та даними програми.
Методи захисту:
1) Екранування даних на виході.
Сценарії використання: метод застосовується в більшості віпадків,
оскільки є одним з базових методів, зазвичай застосовується в комплексі з
методом перевірки даних після отримання.
Принцип дії: Кодування слід застосовувати безпосередньо перед
тим, як керовані користувачем дані записуються на сторінку, оскільки
контекст, у який ви пишете, визначає, який тип кодування вам потрібно
використовувати. Наприклад, значення в рядку JavaScript потребують
іншого типу екранування, ніж у контексті HTML.
У контексті HTML вам слід перетворити значення, які не внесені до
білого списку, на сутності HTML:
< конвертується в: <
> конвертується в: >
Лист
ЧДТУ.22.21091.006 ПЗ
48
Зм Арк №Докум. Підп Дат
а
У контексті рядка JavaScript небуквено-цифрові значення мають бути
екрановані за допомогою Unicode:
< конвертується в: \u003c
> конвертується в: \u003e
Іноді потрібно застосувати кілька рівнів кодування в правильному
порядку. Наприклад, щоб безпечно вставити введені користувачем дані в
обробник подій, вам потрібно працювати як з контекстом JavaScript, так і з
контекстом HTML (Рисунок 2.15). Тож вам потрібно спочатку використати
екранування Unicode, а потім екранування HTML:
Рисунок 2.15 – Приклад рядку що потребує подвійного екранування.
Переваги: є одним з основних та найбільш надійних методів захисту
проти XSS атак.
Недоліки: Метод потребує постійної підтримки та перевірки
правильності виконання, а також ретельного тестування. Даний метод не
захищає повністю від всіх варіацій XSS, тому зазвичай використовується в
комплексі з іншими методами.
2) Перевірка введених даних після отримання.
Сценарії використання: також один з базових методів захисту проти
XSS застосовується в комплексі з методом кодування даних на виході.
Принцип дії: Кодування, ймовірно, є найважливішою лінією захисту
XSS, але цього недостатньо для запобігання вразливості XSS у кожному
контексті. Ви також повинні якомога суворіше перевіряти введені дані в
момент, коли вони вперше отримані від користувача. Перевірка може
відбуватися за допомогою регулярних виразів для певних шаблонів рядків.
Приклади перевірки вхідних даних включають:
Лист
ЧДТУ.22.21091.006 ПЗ
49
Зм Арк №Докум. Підп Дат
а
Якщо користувач надсилає URL-адресу, яка повертатиметься у
відповідях, підтверджуючи, що вона починається з безпечного
протоколу, наприклад HTTP та HTTPS. Інакше хтось може
використати ваш сайт за допомогою шкідливого протоколу,
наприклад javascript або даних.
Якщо користувач надає значення, яке, як він очікує, буде числовим,
перевіряє, що значення насправді містить ціле число. Перевірка цього
введення містить лише очікуваний набір символів. В ідеалі перевірка
введених даних повинна працювати шляхом блокування недійсних
введених даних.
Альтернативний підхід, тобто спроба очистити неправильні вхідні
дані, щоб зробити їх правильними, більш схильний до помилок, і його слід
уникати, де це можливо.
3) Запобігання XSS за допомогою Content Security Policy (CSP)
Сценарії застосування: у випадках коли необхідно додати ще один
рівень захисту проти XSS,
Принцип дії: політика безпеки вмісту (Content Security Policy CSP) є
останньою лінією захисту від міжсайтових сценаріїв. Якщо профілактика
XSS не вдається, можна використовувати CSP, щоб протидіяти XSS,
обмеживши дії зловмисника. CSP дозволяє контролювати різні речі,
наприклад, чи можна завантажувати зовнішні сценарії та чи
виконуватимуться вбудовані сценарії. Щоб розгорнути CSP, вам потрібно
включити заголовок відповіді HTTP під назвою Content-Security-Policy зі
значенням, що містить необхідну політику.
Переваги: правильне використання даної технології значно зменшує
ймовірність успішної реалізації XSS атаки.
Недоліки: цей метод не повністю захищає додаток від XSS атак,
також деякі опції політики не зможуть бути застосовані для додатків які
повинні приймати ресурси з інших сайтів.
Лист
ЧДТУ.22.21091.006 ПЗ
50
Зм Арк №Докум. Підп Дат
а
Приклад: CSP (Рисунок 2.16) виглядає наступним чином:
Рисунок 2.16 – Приклад HTTP відповіді з заголовком CSP
Наведена вище політика визначає, що такі ресурси, як зображення та
сценарії, можна завантажувати лише з того самого джерела, що й головна
сторінка. Таким чином, навіть якщо зловмисник може успішно ввести
корисне навантаження XSS, він може завантажити ресурси лише з
поточного джерела. Це значно зменшує ймовірність того, що зловмисник
може використати вразливість XSS. Якщо вам потрібно завантажувати
зовнішні ресурси, переконайтеся, що ви дозволили лише сценарії, які не
допомагають зловмисникам використовувати ваш сайт. Наприклад, якщо
додати певні домени до білого списку, зловмисник зможе завантажити
будь-який сценарій із цих доменів. По можливості намагайтеся
розміщувати ресурси на власному домені. Якщо це неможливо, ви можете
використовувати політику на основі хешів або nonce, щоб дозволити
сценарії в різних доменах. Nonce — це випадковий рядок, який додається
як атрибут сценарію або ресурсу, який буде виконано, лише якщо
випадковий рядок збігається зі згенерованим сервером. Зловмисник не
зможе вгадати рядок з випадкових символів і, отже, не може викликати
сценарій або ресурс із валідним nonce, тому ресурс не буде завантажено.
Лист
ЧДТУ.22.21091.006 ПЗ
51
Зм Арк №Докум. Підп Дат
а
2.4.3. Аналіз методів захисту проти CSRF атак
CSRF (Cross-site request forgery [11]) — це тип атаки, який
відбувається, коли шкідливий веб-сайт, електронна пошта, блог, миттєве
повідомлення або програма змушує веб-браузер користувача виконувати
небажану дію на надійному сайті, коли користувач пройшов
автентифікацію. Атака CSRF працює, оскільки запити браузера
автоматично включають усі файли cookie, включаючи файли cookie сеансу.
Таким чином, якщо користувач автентифікований на сайті, сайт не може
відрізнити законні авторизовані запити від підроблених автентифікованих
запитів. Цій атаці припиняється, коли використовується належна
авторизація, що означає, що потрібен механізм виклику-відповіді, який
перевіряє особу та повноваження запитувача. Вплив успішної атаки CSRF
обмежується можливостями, відкритими вразливою програмою, і
привілеями користувача. Наприклад, ця атака може призвести до переказу
коштів, зміни пароля або здійснення покупки за допомогою облікових
даних користувача. По суті, атаки CSRF використовуються зловмисником,
щоб змусити цільову систему виконувати певну функцію через браузер
жертви без відома жертви, принаймні до моменту здійснення
несанкціонованої транзакції.
Методи захисту:
1) Використовуйте вбудовані або існуючі реалізації CSRF токенів для
захисту від CSRF атак.
Сценарії застосування: якщо фреймворк має вбудовану реалізацію
технології захисту від CSRF атак.
Принцип дії: Захист за допомогою синхронізуючих токенів
вбудовано в багато фреймворків. Наполегливо рекомендується дослідити,
чи є у фреймворку, який використовується на проекті, опція для досягнення
захисту CSRF за замовчуванням, перш ніж намагатися створювати власну
систему генерації токенів. Наприклад, .NET та Spring мають вбудований
Лист
ЧДТУ.22.21091.006 ПЗ
52
Зм Арк №Докум. Підп Дат
а
захист, який додає маркер до вразливих ресурсів CSRF. На розробників,
натомість, лягає відповідальність за правильну конфігурацію (наприклад,
керування ключами та маркерами) перед використанням цих вбудованих
засобів захисту CSRF, які генерують маркери для захисту вразливих
ресурсів CSRF.
Переваги: простота конфігурації, ретельна та якісна реалізація, що
забезпечує найкращий захист.
Недоліки: не всі веб-фреймворки реалізують дану технологію
захисту.
Приклад: фреймворк Spring (а точніше його частина Spring Security)
для Java, застосовує дану технологію за замовчуванням.
2) Власна реалізація Synchronizer Token Pattern
Сценарії використання: В разі відсутності вбудованого механізму
генерації та обробки CSRF токенів.
Принцип дії: Маркери CSRF мають бути згенеровані на стороні
сервера. Вони можуть бути згенеровані один раз за сеанс користувача або
для кожного запиту. Маркери для кожного запиту є більш безпечними, ніж
токени для кожного сеансу, оскільки діапазон часу, протягом якого
зловмисник може використати вкрадені токени, є мінімальним. Однак це
може спричинити проблеми з зручністю використання. Наприклад, функція
браузера кнопки «Назад» часто перешкоджає тому, що попередня сторінка
може містити маркер, який більше не дійсний. Взаємодія з цією
попередньою сторінкою призведе до фальшивого спрацювання безпеки
CSRF на сервері. У сеансових реалізаціях маркерів після початкової
генерації маркера значення зберігається в сеансі та використовується для
кожного наступного запиту, доки сеанс не закінчиться. Коли клієнт
надсилає запит, серверний компонент повинен перевірити існування та
дійсність маркера в запиті порівняно з маркером, знайденим у сеансі
користувача. Якщо токен не знайдено в запиті або надане значення не
Лист
ЧДТУ.22.21091.006 ПЗ
53
Зм Арк №Докум. Підп Дат
а
відповідає значенню в сеансі користувача, тоді запит слід відхилити. Також
слід розглянути додаткові дії, такі як реєстрація події як потенційної
поточної атаки CSRF.
Токен CSRF має бути:
Унікальним для кожного сеансу користувача.
Секретним.
Непередбачуваним (велике випадкове значення, згенероване
безпечним методом).
Маркери CSRF запобігають CSRF, оскільки без маркера зловмисник
не може створювати дійсні запити до внутрішнього сервера. Для шаблону
синхронізованого маркера маркери CSRF не слід передавати за допомогою
файлів cookie. Маркер CSRF можна передати клієнту як частину корисного
навантаження відповіді, наприклад відповіді HTML або JSON. Потім його
можна передати назад на сервер як приховане поле у формі, що
надсилається, або через запит AJAX як користувацьке значення заголовка
або частину корисного навантаження JSON. Переконайтеся, що маркер не
просочується в журналах сервера або в URL-адресі. Маркери CSRF у
запитах GET потенційно просочуються в кількох місцях, наприклад в історії
браузера, файлах журналів, мережевих утилітах, які реєструють перший
рядок запиту HTTP, і заголовках Referer, якщо захищений сайт посилається
на зовнішній сайт.
Переваги: є повноцінною та самодостатньою протидією CSRF
атакам.
Лист
ЧДТУ.22.21091.006 ПЗ
54
Зм Арк №Докум. Підп Дат
а
Недоліки: свій варіант реалізації зазвичай дуже складний, потребує
багато часу, зусиль, та ретельного тестування (Рисунок 2.17).
Рисунок 2.17 – Приклад використання CSRF токенів у формі.
Вставлення маркера CSRF у настроюваний заголовок HTTP-запиту
через JavaScript вважається більш безпечним, ніж додавання токена в
параметр форми прихованого поля, оскільки він використовує настроювані
заголовки запиту.
3) Подвійне надсилання файлу cookie
Сценарії використання: Якщо підтримувати стан маркера CSRF на
сервері проблематично, альтернативним захистом є використання техніки
подвійного надсилання файлів cookie. Цей метод простий у реалізації та не
має стану.
Принцип дії: У цій техніці ми надсилаємо випадкове значення як у
файлі cookie, так і як параметр запиту, при цьому сервер перевіряє, чи
збігаються значення cookie та значення запиту. Коли користувач відвідує
сайт (навіть до автентифікації, щоб запобігти входу CSRF), сайт повинен
створити (криптографічно надійне) псевдовипадкове значення та
встановити його як файл cookie на комп’ютері користувача окремо від
ідентифікатора сеансу. Тоді сайт вимагає, щоб кожен запит на транзакцію
включав це псевдовипадкове значення як приховане значення форми (або
як параметр/заголовок запиту). Якщо обидва збігаються на стороні сервера,
сервер приймає це як законний запит, а якщо ні, він відхиляє запит. Щоб
підвищити безпеку цього рішення, додайте маркер до зашифрованого
файлу cookie, крім файлу cookie для автентифікації (оскільки вони часто
використовуються в субдоменах), а потім на сервері зіставте його (після
Лист
ЧДТУ.22.21091.006 ПЗ
55
Зм Арк №Докум. Підп Дат
а
розшифрування зашифрованого файлу cookie) з маркером у прихованому
поле форми або параметр/заголовок для викликів AJAX. Це працює,
оскільки субдомен не має можливості перезаписати правильно створений
зашифрований файл cookie без необхідної інформації, наприклад ключа
шифрування. Простішою альтернативою зашифрованим файлам cookie є
HMAC маркер із секретним ключем, відомим лише серверу, і розміщення
цього значення у файлі cookie. Це схоже на зашифрований файл cookie
(обидва вимагають знань, якими володіє лише сервер), але потребує менше
обчислень, ніж шифрування та дешифрування файлу cookie. Незалежно від
того, чи використовується шифрування чи HMAC, зловмисник не зможе
відтворити значення cookie із простого маркера, не знаючи секретів сервера.
Переваги: не залежить від можливості підтримувати стан маркера
CSRF на сервері.
Недоліки: незручний у використанні, також цей метод сповільнює
обробку запитів.
4) Атрибут файлу cookie SameSite
Сценарії застосування: В разі необхідності підвищення стійкості
проти CSRF атак.
Принцип дії: SameSite — це атрибут cookie (схожий на HTTPOnly,
Secure тощо), який спрямований на запобігання атак CSRF. Це визначено в
RFC6265bis. Цей атрибут допомагає браузеру вирішити, чи надсилати
файли cookie разом із міжсайтовими запитами. Можливі значення для цього
атрибута: Lax, Strict або None. Значення Strict запобігає надсиланню файлів
cookie браузером на цільовий сайт у будь-якому міжсайтовому контексті
перегляду, навіть якщо ви переходите за звичайним посиланням.
Наприклад, для веб-сайту, схожого на GitHub, це означатиме, що
якщо користувач, який увійшов у систему, перейде за посиланням на
приватний проект GitHub, опублікованому на корпоративному
дискусійному форумі чи електронною поштою, GitHub не отримає файл
Лист
ЧДТУ.22.21091.006 ПЗ
56
Зм Арк №Докум. Підп Дат
а
cookie сеансу, і користувач не зможе щоб отримати доступ до проекту.
Однак веб-сайт банку не хоче дозволяти посилання на будь-які сторінки
транзакцій із зовнішніх сайтів, тому прапор Strict буде найбільш доречним.
Значення Lax за замовчуванням забезпечує прийнятний баланс між
безпекою та зручністю використання для веб-сайтів, які хочуть
підтримувати сеанс входу користувача після того, як користувач
переходить із зовнішнього посилання. У наведеному вище сценарії GitHub
файл cookie сеансу буде дозволено під час переходу за звичайним
посиланням із зовнішнього веб-сайту, але заблоковано в методах запиту,
схильних до CSRF, таких як POST.
Лише міжсайтові запити, дозволені в режимі Lax, мають навігацію
верхнього рівня, а також є безпечними методами HTTP. Щоб дізнатися
більше про значення SameSite, перегляньте наступний розділ із rfc.
Усі десктопні та майже всі мобільні браузери тепер підтримують
атрибут SameSite. Зауважимо, що Chrome оголосив, що за замовчуванням
позначатиме файли cookie як SameSite=Lax з Chrome 80 (вийшов в лютому
2020 року), і Firefox і Edge планують наслідувати цей приклад. Крім того,
для файлів cookie, позначених як SameSite=None, потрібен прапор Secure.
Важливо зазначити, що цей атрибут має бути реалізований як додатковий
метод глибокого захисту. Цей атрибут захищає користувача через браузери,
які його підтримують, а також містить 2 способи його обійти, як зазначено
в наступному розділі. Цей атрибут не повинен замінювати наявність
маркера CSRF, натомість він має існувати разом із цим маркером, щоб
захистити користувача більш надійним способом.
Переваги: додатково підвищує стійкість проти CSRF атак.
Недоліки: не є повноцінним рішенням для захисту проти атак на
підробку запиту.
Лист
ЧДТУ.22.21091.006 ПЗ
57
Зм Арк №Докум. Підп Дат
а
5) Перевірка походження за допомогою стандартних заголовків
Сценарії застосування: В разі необхідності підвищення стійкості
проти CSRF атак.
Принцип дії: Існує два кроки для реалізації цього методу, обидва з
яких покладаються на перевірку значення заголовка запиту HTTP.
Визначення джерела, з якого надходить запит (походження джерела). Це
можна зробити через заголовки Origin або Referer. Визначення джерела, до
якого спрямовується запит (цільове джерело). На стороні сервера ми
перевіряємо, чи обидва вони збігаються. Якщо вони приймають, ми
приймаємо запит як законний (це означає, що це той самий запит
походження), а якщо ні, ми відхиляємо запит (це означає, що запит
походить із міждоменного домену). Надійність цих заголовків пояснюється
тим фактом, що їх не можна змінити програмно, оскільки вони потрапляють
у список заборонених заголовків, тобто їх може встановити лише браузер.
Визначення походження джерела (через заголовок Origin/Referer).
Якщо присутній заголовок Origin, переконайтеся, що його значення
відповідає цільовому джерелу. На відміну від Referer, заголовок Origin буде
присутній у запитах HTTP, які надходять із URL-адреси HTTPS.
Якщо заголовок Origin відсутній, переконайтеся, що ім’я хоста в
заголовку Referer відповідає цільовому джерелу. Цей метод протидії CSRF
також зазвичай використовується з неавтентифікованими запитами, такими
як запити, зроблені до встановлення стану сеансу, який потрібен для
відстеження маркера синхронізації.
В обох випадках переконайтеся, що перевірка цільового джерела
надійна. Наприклад, якщо ваш сайт example.org, переконайтеся, що
example.org.attacker.com не пройшов вашу перевірку джерела (тобто
встановіть відповідність через кінцевий / після джерела, щоб переконатися,
що ви збігаєтеся з усім джерелом). Якщо жоден із цих заголовків відсутній,
ви можете прийняти або заблокувати запит. Рекомендуємо заблокувати.
Лист
ЧДТУ.22.21091.006 ПЗ
58
Зм Арк №Докум. Підп Дат
а
Крім того, ви можете зареєструвати всі такі випадки, відстежувати їх
варіанти використання/поведінку, а потім розпочати блокування запитів
лише після того, як отримаєте достатньо впевненості.
Можна подумати, що легко визначити джерело цілі, але часто це не
так. Перша думка полягає в тому, щоб просто отримати цільове джерело
(тобто його ім’я хосту та номер порту) з URL-адреси в запиті. Однак сервер
додатків часто знаходиться за одним або декількома проксі-серверами, і
вихідна URL-адреса відрізняється від URL-адреси, яку насправді отримує
сервер додатків. Якщо до вашого сервера додатків безпосередньо
звертаються його користувачі, то використання джерела в URL-адресі є
нормальним, і все готово. Якщо ви перебуваєте за проксі, є кілька варіантів,
які слід розглянути. Налаштуйте свою програму так, щоб вона просто знала
її цільове джерело: це ваша програма, тому ви можете знайти її цільове
джерело та встановити це значення в певному записі конфігурації сервера.
Це був би найбезпечніший підхід, оскільки він визначений на стороні
сервера, тому це надійне значення. Однак це може бути проблематично
підтримувати, якщо ваша програма розгорнута в багатьох місцях,
наприклад, розробка, тестування, контроль якості, виробництво та,
можливо, кілька робочих екземплярів. Встановити правильне значення для
кожної з цих ситуацій може бути складно, але якщо ви можете зробити це
за допомогою якоїсь центральної конфігурації та надати свої екземпляри,
щоб отримати з цього значення, це чудово! (Примітка. Переконайтеся, що
централізоване сховище конфігурацій надійно підтримується, тому що
основна частина вашого захисту CSRF залежить від нього.)
Використовуйте значення заголовка Host: якщо ви бажаєте, щоб
програма знаходила власну ціль, щоб її не потрібно було налаштовувати для
кожного розгорнутого екземпляра, ми рекомендуємо використовувати
сімейство заголовків Host. Призначення заголовка Host — містити цільове
джерело запиту. Але якщо ваш сервер додатків знаходиться за проксі-
Лист
ЧДТУ.22.21091.006 ПЗ
59
Зм Арк №Докум. Підп Дат
а
сервером, значення заголовка Host, швидше за все, змінено проксі-сервером
на цільове джерело URL-адреси за проксі-сервером, яке відрізняється від
вихідної URL-адреси. Це змінене походження заголовка Host не
збігатиметься з джерелом джерела в оригінальних заголовках Origin або
Referer. Використовуйте значення заголовка X-Forwarded-Host: щоб
уникнути проблеми зі зміною проксі-сервером заголовка хосту, існує ще
один заголовок під назвою X-Forwarded-Host, призначення якого полягає в
тому, щоб містити вихідне значення заголовка хосту, яке отримав проксі.
Більшість проксі-серверів передадуть вихідне значення заголовка Host у
заголовок X-Forwarded-Host. Таким чином, це значення заголовка, швидше
за все, буде значенням цільового джерела, яке потрібно порівняти з
джерелом джерела в заголовку Origin або Referer.
Цей метод працює належним чином, якщо в запитах присутні
заголовки джерела або посилання. Хоча ці заголовки включені в більшості
випадків, є кілька випадків використання, де вони не включені (більшість із
них з законних причин для захисту конфіденційності
користувачів/налаштування на екосистему браузера). Нижче наведено деякі
випадки використання:
Internet Explorer 11 не додає заголовок Origin у запит CORS на сайтах
довіреної зони. Заголовок Referer залишиться єдиним показником
походження інтерфейсу користувача. Перегляньте наступні посилання в
Stack Overflow тут і тут. У випадку після переспрямування 302 з
перехресного джерела, Origin не включається в переспрямований запит,
оскільки це може вважатися конфіденційною інформацією, яку не слід
надсилати іншому джерелу. У деяких контекстах конфіденційності для
Origin встановлено значення "null". Наприклад, Заголовок Origin включено
для всіх перехресних запитів джерела, але для тих самих запитів джерела в
більшості браузерів він включений лише в POST/DELETE/PUT. Примітка:
хоча це не рекомендується, багато розробників використовують запити GET
Лист
ЧДТУ.22.21091.006 ПЗ
60
Зм Арк №Докум. Підп Дат
а
для виконання операцій зміни стану. Заголовок посилання не є винятком. Є
кілька варіантів використання, коли заголовок реферера також
пропускається (1, 2, 3, 4 і 5). Добре відомо, що балансувальники
навантаження, проксі-сервери та вбудовані мережеві пристрої видаляють
заголовок реферера з міркувань конфіденційності під час їх реєстрації.
Зазвичай незначний відсоток трафіку підпадає під вищезазначені
категорії (1-2%), і жодне підприємство не захоче втрачати цей трафік.
Однією з популярних технік, які використовуються в Інтернеті, щоб
зробити цю техніку більш зручною для використання, є прийняття запиту,
якщо джерело/реферер відповідає налаштованому списку доменів, «АБО»
нульове значення (тут приклади. Нульове значення охоплює граничні
випадки згадані вище, де ці заголовки не надсилаються). Зауважте, що
зловмисники можуть використати це, але люди вважають за краще
використовувати цю техніку як засіб глибокого захисту через невеликі
зусилля, пов’язані з її розгортанням.
Переваги: підвищує захист проти атак на міжсайтову підміну запиту.
Недоліки: не є повноцінним рішенням для захисту проти вказаної
атаки. Можуть бути проблеми з реалізацією, якщо для серверу
використовуються балансувальники навантаження, проксі-сервери та
вбудовані мережеві пристрої.
6) Використання файлу cookie з префіксом __Host-
Сценарії застосування: В разі необхідності підвищення стійкості
проти CSRF атак.
Принцип дії: якщо файл cookie має префікс __Host-, напр. Set-Cookie:
__Host-token=RANDOM; path=/; protect cookies: то в нього не можна
(пере)записати дані з іншого субдомену. Необхідний шлях /. має бути
позначено як безпечний (тобто той який не може надсилатися через
незашифрований HTTP).
Лист
ЧДТУ.22.21091.006 ПЗ
61
Зм Арк №Докум. Підп Дат
а
Переваги: Станом на липень 2020 року префікси cookie
підтримуються всіма основними браузерами, крім Internet Explorer.
Перегляньте проект мережі розробників Mozilla та IETF для отримання
додаткової інформації про префікси cookie.
Недоліки: не є повноцінним методом захисту проти CSRF атак.
7) Використання спеціального заголовка запиту
Сценарії застосування: у випадках коли додавання токенів CSRF,
подвійне надсилання файлу cookie, шифрування маркера або іншого
захисту, який передбачає зміну інтерфейсу користувача, може бути
складним або іншим чином проблематичним.
Принцип дії: цей захист ґрунтується на обмеженні політики того
самого джерела (SOP), згідно з яким для додавання спеціального заголовка
можна використовувати лише JavaScript і лише в межах свого джерела. За
замовчуванням браузери не дозволяють JavaScript робити перехресні
запити джерела з користувацькими заголовками. Якщо це стосується вашої
системи, ви можете просто перевірити наявність цього заголовка та
значення на всіх кінцевих точках AJAX на стороні сервера, щоб захиститися
від атак CSRF.
Переваги: зазвичай не вимагає змін інтерфейсу користувача та не
вводить будь-який стан на стороні сервера, що особливо привабливо для
служб REST. Ви завжди можете додати свій власний заголовок і значення,
якщо це бажано.
Недоліки: Ця техніка, очевидно, працює для викликів AJAX, але теги
<form> все одно необхідно захищати за допомогою підходів, описаних
вище, наприклад маркерів. Крім того, конфігурація CORS також має бути
надійною, щоб це рішення працювало ефективно (оскільки спеціальні
заголовки для запитів, що надходять з інших доменів, запускають перевірку
CORS перед польотом).
8) Захист CSRF на основі взаємодії з користувачем
Лист
ЧДТУ.22.21091.006 ПЗ
62
Зм Арк №Докум. Підп Дат
а
Сценарії застосування: у випадках коли є доцільним залучити
користувача до транзакції, щоб запобігти неавторизованим операціям
(підробленим через CSRF чи іншим чином).
Принцип дії: нижче наведено кілька прикладів методів, які можуть
діяти як сильний захист CSRF, якщо їх правильно впровадити.
Re-Authentication Механізм авторизації (по паролю або надійніше)
Одноразовий токен
CAPTCHA (зазвичай перевага надається новішим версіям CAPTCHA
без взаємодії з користувачем або візуального збігу шаблонів) Хоча це
дуже сильний захист проти CSRF, він може значно вплинути на
роботу користувача. Таким чином, вони, як правило,
використовуватимуться лише для важливих для безпеки операцій
(таких як зміна пароля, грошові перекази тощо).
Переваги: вказані методи можуть значно підвищити захист проти
CSRF атак.
Недоліки: можуть використовуватися проти
2.4.4. Аналіз методів захисту проти атаки Path traversal
Перегляд каталогу (також відомий як обхід шляху до файлу [12]) —
це вразливість веб-безпеки, яка дозволяє зловмиснику читати довільні
файли на сервері, на якому виконується додаток. Це може включати код і
дані програми, облікові дані для внутрішніх систем і конфіденційні файли
операційної системи. У деяких випадках зловмисник може мати можливість
писати в довільні файли на сервері, дозволяючи йому змінювати дані або
поведінку програми та зрештою отримати повний контроль над сервером.
Методи протидії:
1) Уникання передачі вхідних даних користувача в API файлової
системи
Лист
ЧДТУ.22.21091.006 ПЗ
63
Зм Арк №Докум. Підп Дат
а
Сценарії застосування: застосовується у випадках коли є
можливість не використовувати введені користувачем дані для роботи з
файловою системою.
Принцип дії: перероблення функціоналу додатку таким чином, щоб
уникнути безпосереднього впливу вхідних даних на файлову систему.
Переваги: найбільш надійний захисті від “підміни шляху”
Недоліки: застосовується лише в тих випадках коли архітектура
додатку була неправильно побудована, і вхідні дані використовуються для
взаємодії з файловою системою без необхідності в цьому.
2) Попередня перевірка параметрів файлового імені
Сценарії застосування: у випадках коли введені користувачем дані
необхідно використати для взаємодії з файловою системою.
Принцип дії: для взаємодії з файловою системою використовується
не повна назва файлу, а лише певні параметри (номер, id користувача і т.д.),
ці параметри повинні проходити сувору перевірку на предмет наявності
лише необхідних символів, довжини та інших параметрів визначених
вимогами архітектури або конкретної задачі.
Переваги: метод є відносно надійним для забезпечення захисту від
підміни шляху, також він є досить простим в реалізації.
Недоліки: реалізація перевірки введених даних в кожних місцях де
вони мають використовуватися для роботи з файловою системою повинна
дуже ретельно тестуватися на предмет вразливостей.
3) Використання білого списку
Сценарії використання: у випадках коли кількість файлів до яких
повинен надаватися доступ є обмеженою або сталою.
Принцип дії: полягає в перевірці введених даних на предмет
відповідності з наявними в білому списку.
Переваги: метод простий та надійний.
Недоліки: коло застосувань дуже обмежене.
Лист
ЧДТУ.22.21091.006 ПЗ
64
Зм Арк №Докум. Підп Дат
а
4) Реалізація принципу найменших привілеїв
Сценарії застосування: для підвищення рівню захисту проти атаки
path traversal.
Принцип дії: принцип найменших привілеїв — це політика ІТ-
безпеки, яка стверджує, що суб’єкту, який запитує доступ до ресурсу, слід
надавати лише мінімально необхідні права. У принципі також зазначено,
що ці права мають діяти протягом якомога коротшого терміну. Обов’язково
надайте користувачам мінімально необхідні дозволи для законної взаємодії
з веб-сервером/програмою.
Переваги: підвищує захист проти низки атак, метод простий в
реалізації.
Недоліки: є недружелюбним до користувача, і відповідно не дуже
зручним та потребує ретельного тестування.
2.4.5. Аналіз методів захисту проти атаки XML External Entity
Ця атака відбувається, коли ненадійний XML-вхід, що містить
посилання на зовнішню сутність, обробляється погано налаштованим
аналізатором XML [13].
Атака може призвести до розкриття конфіденційних даних, відмови в
обслуговуванні, підробки запитів на стороні сервера (SSRF), сканування
портів з точки зору комп’ютера, на якому розташований парсер, та інших
впливів на систему.
Методи захисту:
1) Повне вимкнення DTD
Сценарії застосування: застосовується в більшості випадків,
оскільки дані передані в xml зазвичай не потребують використання
зовнішніх сутностей.
Принцип дії: вимкнення DTD (Doc-Type Declaration) відключає
парсинг зовнішніх сутностей, що унеможливлює виконання XXE атаки.
Лист
ЧДТУ.22.21091.006 ПЗ
65
Зм Арк №Докум. Підп Дат
а
Вимкнення DTD також захищає синтаксичний аналізатор від атак відмови
в обслуговуванні (DOS), таких як Billion Laughs. Якщо неможливо повністю
вимкнути DTD, тоді зовнішні сутності та оголошення типу зовнішнього
документа потрібно вимкнути у спосіб, який є специфічним для кожного
аналізатора.
Переваги: повністю унемоливлює виконання XXE атаки.
Недоліки: немає.
Приклад: залежно від синтаксичного аналізатора метод має бути
подібним до такого (Рисунок 2.18):
Рисунок 2.18 – Приклад повного вимкнення DTD.
2.4.6. Аналіз методів захисту проти атаки Clickjacking
Клікджекінг [14], також відомий як «атака відшкодування інтерфейсу
користувача», — це коли зловмисник використовує кілька прозорих або
непрозорих шарів, щоб обманом змусити користувача натиснути кнопку чи
посилання на іншій сторінці, коли він мав намір натиснути сторінку
верхнього рівня. Таким чином, зловмисник «викрадає» кліки, призначені
для його сторінки, і спрямовує їх на іншу сторінку, яка, швидше за все,
належить іншій програмі, домену або обом. Використовуючи подібну
техніку, натискання клавіш також можна перехопити. Завдяки ретельно
розробленій комбінації таблиць стилів, фреймів і текстових полів
користувач може змусити повірити, що він вводить пароль до своєї
електронної пошти або банківського рахунку, а натомість вводить пароль у
невидимий фрейм, контрольований зловмисником.
Методи захисту:
Лист
ЧДТУ.22.21091.006 ПЗ
66
Зм Арк №Докум. Підп Дат
а
1) Налаштування X-Frame-Options
Сценарії застосування: якщо додаток не потребує функції
фреймування, або є можливість обмежити дану опцію.
Принцип дії: необхідно правильно налаштувати відповідні заголовки
відповіді для директиви Frame-Ancestors політики безпеки контенту (CSP),
вони вкажуть браузеру не дозволяти відкриття фреймів з інших доменів, і
фрейму додатку в інших доменах. Старіші HTTP-заголовки X-Frame-
Options використовуються для зворотньої сумісності зі старішими
браузерами.
Переваги: є найбільш надійним захистом проти Clickjacking атаки.
Недоліки: потребує ретельного ручного тестування.
Приклад: в Spring Security повну заборону x-Frame-Options можна
увімкнути наступним чином (Рисунок 2.19):
Рисунок 2.19 – Вимкнення x-Frame-Options.
2.4.7. Висновки до розділу
В даному розділі було розглянуто складові етапи циклу розробки,
проаналізовано та класифіковано методи захисту, що застосовуються під
час циклу розробки.
Результати проведеного аналізу показують, що першочерговими для
впровадження є “методи автентифікації та авторизації”, оскільки формують
ядро системи керування привілеями користувача і їхнє застосування
залежить лише від архітектури додатку й вимог до системи.
Також були проаналізовані загальні методи виявлення та ліквідації
вразливостей, результат аналізу показав, що вказані методи легко
інтегрувати навіть у громіздкі додатки, але не всі з них підходять для будь-
Лист
ЧДТУ.22.21091.006 ПЗ
67
Зм Арк №Докум. Підп Дат
а
якого проекту, рішення про впровадження таких методів команда
розробників повинна приймати на основі наявного протоколу розробки та
її інтенсивності.
Окрім цього були проаналізовані методи спрямовані на захист проти
конкретних вразливостей, аналіз показав що зазвичай проти вразливостей
існує один чи два канонічних і достатніх методи для протидії кожній
вразливості, всі інші згадані методи є доповненнями або альтернативами у
випадках коли реалізація канонічних методів є проблематичною.
Отже, даний аналіз може бути використаний для спрощення побудови
системи методів захисту для веб-додатків на основі архітектури й наявних
технологій в проекті, а також дає можливість відслідкувати конфліктуючі
методи, що не можуть бути включені до однієї системи.
Лист
ЧДТУ.22.21091.006 ПЗ
68
Зм Арк №Докум. Підп Дат
а
РОЗДІЛ 3: СТВОРЕННЯ МЕТОДИКИ ВПРОВАДЖЕННЯ
СИСТЕМИ МЕТОДІВ ЗАХИСТУ НА ОСНОВІ ПРОВЕДЕНОГО
АНАЛІЗУ
Метою даного розділу є розробка методики, що допоможе
сформувати систему методів захисту що може бути впроваджена найбільш
ефективним способом для зменшення витрат ресурсів часу та фінансів на
впровадження подібних систем.
3.1. Виявлення впливу методів застосованих на етапі підготовки
Методи що застосовуються на етапі підготовки в більшості своїй
стандартизовані і застосовуються в тому порядку в якому визначає
спеціаліст з безпеки базуючись на ризиках що можуть завдати найбільшої
шкоди, тому в даній методиці вважається недоцільним огляд і класифікація
методів що застосовуються на етапі розробки. Натомість важливим
пунктом є можливий вплив методів, що можуть бути застосовані на етапі
підготовки до розробки на методи що застосовуються при безпосередній
розробці.
Аналіз такого впливу є першочерговим перед початком застосування
методики по побудові системи методів захисту.
Прикладами впливу, що варто завжди розглядати перед створенням
системи методів захисту є:
VPN компанії може впливати на методи ручного, функціонального та
інтеграційного тестування в тих випадках коли додаток, що потрібно
тестувати, повинен тримати зв’язок з іншим зовнішнім додатком.
Балансувальники, брандмауери для веб-додатків, проксі-сервери та
інші мережеві пристрої, програмні чи апаратні, можуть керувати
заголовками HTTP запитів, що може вплинути на методи, що
базуються на використанні HTTP заголовків.
Лист
ЧДТУ.22.21091.006 ПЗ
69
Зм Арк №Докум. Підп Дат
а
3.2. Визначення можливості впровадження методу.
Першим кроком до створення системи є визначення можливих для
впровадження методів, адже немає сенсу розглядати методи що з тієї чи
іншої причини не можуть бути включені до системи.
Для того, щоб визначити, чи можливо впровадити метод в проект
розробки, необхідно, щоб виконувалися наступні умови:
Кількість наявних ресурсів достатня для впровадження.
Наявні технологій достатньо або їх можливо впровадити для
реалізації методу.
Впровадження методу не спричинить конфлікти з наявними
необхідними технологіями.
Впровадження методу не протирічить вимогам до додатку.
Якщо всі наведені умови виконуються то метод можливо включити
до системи.
3.3. Визначення необхідності впровадження методу.
Наступним пунктом методики є визначення необхідності
впровадження методу, чи групи методів.
Для спрощення визначення необхідності методу, потрібно
класифікувати методи за призначенням на наступні:
Фундаментальні;
Канонічні;
Альтернативні;
Додаткові.
Фундаментальними методами є ті що впроваджуються в тій чи іншій
формі, практично завжди, незалежно від архітектури чи технологій, до
таких методів належать наступні:
Методи автентифікації та авторизації.
Лист
ЧДТУ.22.21091.006 ПЗ
70
Зм Арк №Докум. Підп Дат
а
Методи автоматизованого тестування.
Метод поверхневого ручного тестування.
Метод регулярного оновлення бібліотек та інших залежностей
додатку.
Метод обробки вхідних даних.
Метод впровадження протоколу SSL/TLS.
До канонічних ми віднесемо ті методи, що є основними і достатніми
в більшості випадків для захисту проти певних загроз. Прикладом таких
методів є:
Метод використання параметризованих запитів (Prepared Statements)
для протидії SQL-ін’єкціям.
Комплекс методів екранування даних перед виведенням та
перевіркою даних при введенні для протидії XSS атакам.
Метод використання вбудованої або існуючі реалізації CSRF токенів
для захисту від CSRF атак.
Метод уникання передачі вхідних даних від користувача в API
файлової системи для протидії Path Traversal атакам.
Метод повного вимкнення або налаштування DTD в налаштуваннях
парсеру для протидії XXE атакам.
Метод налаштування X-Frame-Options для протидії Clickjacking
атакам.
До альтернативних методів ми віднесемо ті методи, які можуть бути
використані як альтернатива канонічним у випадку якщо впровадження
канонічного методу є неможливим. До таких методів відносяться наступні:
Метод екранування символів для захисту проти SQL-ін'єкцій.
Метод створення власної реалізації Synchronizer Token Pattern для або
Методи захисту CSRF на основі взаємодії з користувачем для
протидії реалізації CSRF атаки.
Лист
ЧДТУ.22.21091.006 ПЗ
71
Зм Арк №Докум. Підп Дат
а
Методи попередньої перевірки параметрів файлового імені для або
використання білого списку для протидії Path Traversal.
До додаткових методів ми віднесемо ті які використовуються для
підвищення рівня захисту окремо або в комплексі з канонічними чи
альтернативними методами захисту, тобто до таких методів можна віднести
наступні:
Метод ретельного тестування на проникнення.
Метод аудиту та журналювання.
Метод впровадження статичного аналізатору коду.
Метод перевірки та очищення вхідних даних для додаткового захисту
проти SQL-ін'єкцій.
Метод додаткового захисту проти XSS за допомогою налаштування
Content Security Policy.
Методи використання атрибуту файлу cookie SameSite, використання
спеціального заголовка запиту, перевірки походження за допомогою
стандартних заголовків та метод використання файлу cookie з
префіксом __Host- для підвищення рівня захисту проти CSRF атак.
Метод реалізації принципу найменших привілеїв.
Тепер коли ми класифікували методи, то можемо сформувати
ієрархію правил для визначення необхідності використання того чи іншого
методу.
Для визначення необхідності методу потрібно щоб метод підпадав
хоча б під одне з наступних правил:
1) Метод є фундаментальним і відповідає вимогам до додатку.
2) Метод є канонічним чи альтернативним, запобігає загрозі, яка є
ймовірною та не конфліктує з наявними в системі методами.
3) Метод є додатковим і може бути застосованим для підвищення
захисту в тих випадках коли вимоги до безпеки додатку
Лист
ЧДТУ.22.21091.006 ПЗ
72
Зм Арк №Докум. Підп Дат
а
класифікуються як високі, тобто ті які потребують багаторівневого
захисту проти загроз.
Якщо виконується одне правил, то метод можна класифікували як
необхідний для впровадження.
3.4. Визначення пріоритету впровадження методу.
Першочергово повинні впроваджуватися фундаментальні методи,
оскільки вони задають основу для системи захисту. Для того щоб визначити
подальший пріоритет впровадження, методів в системі, необхідно
визначити чи є методи легкими та/або гнучкими в провадженні.
Легкі в провадженні методи – це методи, що не потребують великих
витрат часу й зусиль на впровадження.
Гнучкі в провадженні методи – це методи, що можуть бути
впроваджені в систему поступово, відповідно негнучкими є методи, що
повинні впроваджуватися відразу повністю.
До легких в провадженні методів зазвичай належать:
Метод аудиту та журналювання.
Методи автоматизованого тестування.
Метод поверхневого ручного тестування.
Метод використання параметризованих запитів (Prepared Statements)
для протидії SQL-ін’єкціям.
Метод повного вимкнення або налаштування DTD в налаштуваннях
парсеру для протидії XXE атакам.
Метод налаштування X-Frame-Options для протидії Clickjacking
атакам.
Метод використання вбудованої або існуючі реалізації CSRF токенів
для захисту від CSRF атак.
Лист
ЧДТУ.22.21091.006 ПЗ
73
Зм Арк №Докум. Підп Дат
а
Метод додаткового захисту проти XSS за допомогою налаштування
Content Security Policy.
В свою чергу до гнучких в провадженні методів зазвичай належать
наступні:
Метод регулярного оновлення бібліотек та інших залежностей
додатку.
Метод обробки вхідних даних.
Метод аудиту та журналювання.
Методи автоматизованого тестування.
Метод обробки вхідних даних.
Метод використання вбудованої або існуючі реалізації CSRF токенів
для захисту від CSRF атак.
Комплекс методів екранування даних перед виведенням та
перевіркою даних при введенні для протидії XSS атакам.
Метод використання параметризованих запитів (Prepared Statements)
для протидії SQL-ін’єкціям.
Як результат вище вказаної класифікації та аналізу проведеного в
минулих розділах ми визначили залежності між методами та можемо
використати ці дані для визначення подальшого пріоритету впровадження,
керуючись наступними правилами:
Першочерговими впроваджуються фундаментальні методи, потім всі
інші.
В межах груп методів рекомендується слідувати наступному порядку
впровадження методів:
1) Методи що є перепоною для реалізації інших методів.
2) Методи без залежностей реалізації.
3) Всі інші.
Лист
ЧДТУ.22.21091.006 ПЗ
74
Зм Арк №Докум. Підп Дат
а
Методи без залежностей та всі інші, що не є перепоною в реазілації
інших методів впроваджуються в наступній послідовності:
1) Легкі та одночасно гнучкі у впровадженні методи.
2) Легкі у впровадженні методи.
3) Гнучкі у впровадженні методи.
Даний пріоритет є рекомендованим для найбільш оптимізованого
впровадження, але для повноти даного методу, також необхідно
враховувати ймовірність руйнівних загроз для правильного надання
пріоритету впроваджуваним методам. Вирахування ймовірності тієї чи
іншої загрози, а також збитки що вона може завдати є частиною роботи
аналітика з безпеки і його завдання також. Після обрахунків, аналітик
повинен визначити пріоритетність того чи іншого методу сам.
3.5. Приклад застосування методики до веб-додатку
Для застосування методики створення системи методів захисту для
нового проекту ми можемо керуватися лиш наявними вимогами до додатку
та будувати дану систему з нуля. Дану методику можна застосувати також
до вже існуючого додатку, в такому разі необхідно визначити котрі методи
захисту вже задіяні для даного додатку, та позначити дані методи як методи
з нульовим пріоритетом, оскільки їхня реалізація вже присутня, а отже
необхідності у впровадженні методів немає.
В якості веб-додатку можна розглянути один з інсуючих open-source
проектів, для прикладу візьмемо сервіс Aliexpress (best.aliexpress.com)[16].
Згідно інформації про даний веб-сервіс отриманої з ресурсу Wappalyzer, він
має наступний стек технологій:
Мови програмування: Java;
Веб-фреймворки: Spring;
Веб-сервер: Tengine;
JavaScript фреймворки: React;
Лист
ЧДТУ.22.21091.006 ПЗ
75
Зм Арк №Докум. Підп Дат
а
Довірений центр сертифікації: DigiCert;
Спеціальні технології безпеки: HSTS;
Технології тестування: JUnit:
Додаткові утиліти: Postman;
Враховуючи наявну інформацію ми можемо відмітити, ті методи
захисту що, скоріш за все, були вже застосовані до даного сервісу.
Визначимо фундаментальні методи захисту.
Система автентифікації та авторизації, включає два методи,
автентифікація по формі, та SSO через соціальні мережі (Рисунок 3.1).
Рисунок 3.1 – Сторінка входу Aliexpress.
Лист
ЧДТУ.22.21091.006 ПЗ
76
Зм Арк №Докум. Підп Дат
а
Зважаючи на те, що даний сервіс, використовує протокол HTTPS та
навіть використовує технологію HSTS, яка вказує браузеру який , ми
можемо відмітити що даний сервіс впровадив метод підключення TLS
(Рисунок 3.2).
Рисунок 3.2 – Використання сервісом протоколу HTTPS.
Також як підтвердження серйозного наявного рівню захисту можна
вказати, наступні дані (Рисунок 3.3).
Рисунок 3.3 – Дані про систему мережевого захисту Aliexpress.
Лист
ЧДТУ.22.21091.006 ПЗ
77
Зм Арк №Докум. Підп Дат
а
Враховуючи серйозний підхід до впровадження системи захисту, та
наявності даних про використання технології JUnit можна зробити
висновок, що в проект також впроваджені всі рівні тестування, окрім
ретельного тестування на проникнення про використання якого інформації
немає.
Отже, всі фундаментальні методи захисту вже впроваджені в дану
розробку.
Також в результаті тестування виявлено що ресурс має додатковий
захист у вигляді Брандмауера для веб-додатків (Рисунок 3.4).
Рисунок 3.4 – Робота брандмауеру після спроби злому Aliexpress.
Враховуючи наявні дані можна зробити висновок, що в Aliexpress
використовують мінімум дворівневий захист від будь яких атак через вхідні
дані, тобто всі канонічні чи альтернативні методи для запобігання реалізації
загроз включені до системи захисту, й окрім того захист надає Брандмауер.
Всі методи окрім методів протидії PathTraversal так як в даному
методі немає необхідності, оскільки сервіс не взаємодіє з файловим API
серверу.
Лист
ЧДТУ.22.21091.006 ПЗ
78
Зм Арк №Докум. Підп Дат
а
Що до додаткових методів, то ми також можемо виключити зі списку
додаткового захисту метод захисту проти XSS за допомогою налаштування
Content Security Policy, оскільки він вже присутній (Рисунок 3.5).
Рисунок 3.5 – Заголовки відповіді від Aliexpress.
Отже, всі інші методи про які не вдалося здобути інформацію
вважатимемо відсутніми. Тобто нам необхідно розглянути всі додаткові
методи захисту на предмет додавання до наявної системи, вважаючи що це
відповідає вимогам.
Тобто потрібно розглянути наступні методи на предмет
впровадження для підвищення рівня захищеності додатку:
Метод ретельного тестування на проникнення.
Метод аудиту та журналювання.
Метод впровадження статичного аналізатору коду.
Метод реалізації принципу найменших привілеїв.
Згідно алгоритму надання пріоритету для впровадження, спочатку ми
повинні впровадити метод аудиту та журналювання, оскільки він легкий та
водночас гнучкий у впровадженні.
Потім необхідно впровадити метод використання статичного
аналізатору або метод ретельного тестування на проникнення.
І в кінці впровадити метод реалізації принципу найменших привілеїв.
Лист
ЧДТУ.22.21091.006 ПЗ
79
Зм Арк №Докум. Підп Дат
а
3.5. Висновки до розділу
В даному розділі було проведено детальну по реалізації методики
створення системи методів захисту для подальшого впровадження у веб-
додаток для підвищення рівня захищеності додатку.
В процесі створення методики вдалося класифікувати методи за
різними критеріями, а саме: призначенням, простотою впровадження.
Також було сформовано правила для:
визначення залежностей методів
визначення можливості впровадження методу
визначення необхідності впровадження методу
визначення пріоритету впровадження
В результаті було проведено випробовування методики на існуючому
додатку, а саме було проаналізовано вже наявні методи захисту що
використовує додаток, після чого було визначено методи, необхідні для
впровадження і сформовано найбільш оптимальну пріоритетність даних
методів для поступового впровадження в систему.
Отже ми можемо стверджувати що створена методика є
універсальною і може бути використана для спрощення побудови системи
методів захисту, незалежно від технологій що застосовані у веб-додатку, і
формування пріоритетності їх впровадження для підвищення ефективності
системи, що повинно зменшити витрати на пошук, аналіз та впровадження
необхідних методів захисту.
Лист
ЧДТУ.22.21091.006 ПЗ
80
Зм Арк №Докум. Підп Дат
а
ВИСНОВОК
Отже в результаті даної роботи був проведений аналіз етапів
підготовки до розробки на предмет методів захисту, що повинні бути
впроваджені на даному етапі для забезпечення придатних умов для
подальшої розробки, також було наведення рекомендації для підвищення
кваліфікації працівників, для підвищення обізнаності в плані інформаційної
безпеки, що повинно зменшити ризик викриття конфіденційної інформації
ще перед початком розгортання самого додатку.
Також було проведено аналіз етапу самої розробки на предмет загроз,
що можуть бути реалізовані та методів захисту, що їм запобігають, в
процесі аналізу, методи були розглянуті на предмет сценаріїв
використання, принципу дії, переваг та недоліків, також було наведено
приклади з впровадження розглянутих методів.
Дані, отримані в результаті аналізу, були використані для реалізації
методики впровадження методів захисту як системи методів, в процесі
створення методики було систематизовано та класифіковано методи
захисту, що дозволило спростити створення самої методики та сформувати
правила визначення методів, що повинні бути включені в систему, також в
результаті класифікації були визначені правила надання пріоритету
впровадження для того чи іншого методу системи.
Створена методика була протестована на предмет універсальності в
застосуванні та ефективності. Дану методику було застосовано до веб
сервісу Aliexpress для виявлення вже наявних методів та формування
системи методів необхідних для підвищення захисту додатку.
Лист
ЧДТУ.22.21091.006 ПЗ
81
Зм Арк №Докум. Підп Дат
а
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. How Do You Protect Confidential Information in the Workplace?
[Електронний ресурс] – Режим доступу до ресурсу: https://www.blue-
pencil.ca/how-do-you-protect-confidential-information-in-the-
workplace/.
2. 9 Ways to Make your Company Network Secure [Електронний ресурс] –
Режим доступу до ресурсу: https://tdwi.org/articles/2019/04/23/dwt-all-
9-ways-to-make-your-company-network-secure.aspx.
3. How to Prevent DDoS Attacks: 7 Tried-and-Tested Methods
[Електронний ресурс] – Режим доступу до ресурсу:
https://phoenixnap.com/blog/prevent-ddos-attacks.
4. Keeping Your Computer Safe while Working from Home [Електронний
ресурс] – Режим доступу до ресурсу:
https://www.safewise.com/working-from-home-online-safety/.
5. 12 Essential Security Awareness Training Topics for 2022 [Електронний
ресурс] – Режим доступу до ресурсу: https://blog.usecure.io/12-
security-awareness-topics-you-need-to-know-in-2020.
6. Огляд способів і протоколів автентифікації у веб-прикладеннях
[Електронний ресурс] – Режим доступу до ресурсу:
https://habr.com/ru/company/dataart/blog/262817/.
7. Protecting against sql injection [Електронний ресурс] – Режим доступу
до ресурсу: https://www.hacksplaining.com/prevention/sql-injection.
8. What is SQL Injection (SQLi) and How to Prevent It [Електронний
ресурс] – Режим доступу до ресурсу:
https://www.acunetix.com/websitesecurity/sql-injection/.
9. SQL Injection Prevention Cheat Sheet [Електронний ресурс] – Режим
доступу до ресурсу:
Лист
ЧДТУ.22.21091.006 ПЗ
82
Зм Арк №Докум. Підп Дат
а
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention
_Cheat_Sheet.html.
10. How to prevent XSS [Електронний ресурс] – Режим доступу до
ресурсу: https://portswigger.net/web-security/cross-site-
scripting/preventing.
11. Cross-Site Request Forgery Prevention [Електронний ресурс] – Режим
доступу до ресурсу:
https://cheatsheetseries.owasp.org/cheatsheets/Cross-
Site_Request_Forgery_Prevention_Cheat_Sheet.html.
12. What is directory traversal, and how to prevent it? [Електронний
ресурс] – Режим доступу до ресурсу: https://portswigger.net/web-
security/file-path-traversal.
13. XML External Entity Prevention Cheat Sheet [Електронний ресурс] –
Режим доступу до ресурсу:
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Pre
vention_Cheat_Sheet.html.
14. Clickjacking [Електронний ресурс] – Режим доступу до ресурсу:
https://owasp.org/www-community/attacks/Clickjacking.
15. What Is the Principle of Least Privilege? [Електронний ресурс] –
Режим доступу до ресурсу:
https://www.paloaltonetworks.com/cyberpedia/what-is-the-principle-of-
least-
privilege#:~:text=The%20principle%20of%20least%20privilege%20(Po
LP)%20is%20an%20information%20security,to%20complete%20a%20r
equired%20task.
16. Aliexpress technology stack [Електронний ресурс] – Режим доступу
до ресурсу: https://www.wappalyzer.com/lookup/best.aliexpress.com/.
Лист
ЧДТУ.22.21091.006 ПЗ
83
Зм Арк №Докум. Підп Дат
а