4-1 Етичний хакінг / ЛБ - 01_2 Основи аналізу вразливостей та етичний хакінг моделі безпеки ASP.NET
.docxМіністерство освіти і науки України
Харківський національний університет радіоелектроніки
Факультет Інфокомунікацій .
(повна назва)
Кафедра Інфокомунікаційної інженерії імені В.В. Поповського .
(повна назва)
ЗВІТ
з лабораторної роботи №1
з дисципліни
Основи аналізу вразливостей та етичний хакінг
Тема заняття: Основи аналізу вразливостей та етичний хакінг моделі безпеки ASP.NET
2020 р.
МЕТА РОБОТИ
Метою лабораторної роботи є отримання практичних та теоретичних знань щодо основ аналізу вразливостей та етичного хакінгу моделі безпеки ASP.NET
ХІД ВИКОНАННЯ РОБОТИ
1. Наведіть приклади потенційних загроз програмного забезпечення в банківській сфері.
Небезпеку і загрозу для програмного забезпечення можуть представляти також різні шкідливі для носія інформації комп'ютерні віруси, програмні закладки, які здатні зруйнувати введені коди.
Проникнення у систему через комунікаційні канали зв'язку з присвоєнням повноважень легального користувача з метою підробки, копіювання або знищення інформації. Реалізується розпізнаванням або підбором паролів і протоколів, перехопленням паролів при негласному підключенні до каналу зв'язку під час сеансу, дистанційним перехопленням паролів у результаті отримання та обробки побічного електромагнітного випромінювання
Негласна перебудова устаткування або програмного забезпечення з метою впровадження засобів несанкціонованого доступу до інформації (програм-перехоплювачів і «троянських коней», апаратури аналізу інформації тощо), а також знищення інформації або устаткування (наприклад, за допомогою програм–вірусів, ліквідаторів із дистанційним управлінням тощо);
Знищення інформації або створення збоїв в комп'ютерній системі за допомогою вірусів для дезорганізації діяльності банку. Реалізується шляхом внесення вірусів у систему в неробочий час, підміни ігрових програм, або користування співробітником банку «подарунком» у вигляді нової комп'ютерної гри;
Використання програмних засобів для подолання захисних можливостей системи
За частотою прояву навмисні загрози можна розташувати у такій послідовності:
копіювання і викрадення програмного забезпечення;
несанкціоноване введення даних;
зміна або знищення даних на магнітних носіях;
викрадення інформації;
модифікація інформації (порушення цілісності інформації) –зміна користувачем або процесом інформації, що міститься в об'єкті, наприклад: зміна програм обробки, даних тощо;
блокування інформації – дії, в наслідок яких унеможливлюється доступ до інформації, наприклад: неможливість використання інформації, тобто припинення доступу до інформації користувачам;
2. Наведіть приклади наслідків невиконання правил безпечного коду.
Переповнення буфера (стека, купи, переповнення в результаті помилок індексації масивів, переповнення в результаті використання некоректного кодування).
Використання зловмисниками ПЗ або його служби, запущеного з високими привілеями (прикладів багато, і вони очевидні).
Слабкі випадкові числа.
Слабка криптографія. Потрібно використання по можливості короткострокових (сеансових) ключів. Аутентифікаційні дані повинні зберігатися строго централізовано, а оброблятися – локально.
Немає універсального захисту конфіденційних даних. Необхідно використання шифрування даних потужним симетричним алгоритмом.
Небезпека вхідних даних SQL-injection, XSS. Необхідно особливу увагу всякого роду регулярним виразам; строгий контроль коректності і довжини вхідних даних і їх фільтрація. Вказувати повні шляхи в адресах, представлені в канонічній формі
Без захисту cookie-файлів можлива реалізація несанкціонованого доступу до інформації, що захищається (облікових записів користувачів, сертифікатам і т.п.), що міститься в cookies-файлах, під час їх зберігання чи передачі, в режимі читання (розкриття конфіденційності) або запису (внесення змін для реалізації загрози підміни довіреного користувача).
3. Наведіть приклад як може бути влаштований багаторівневий захист програмного забезпечення в банківській сфері.
Безпека в системі забезпечується розподілом прав доступу користувачів до її інформаційних ресурсів. Керування статичним доступом досягається за допомогою внутрішніх засобів СУБД, наприклад, створенням ролей користувачів та призначенням у їх рамках прав на доступ до окремих представлень, таблиць із словника даних і до обмеженої множини процедур, які зберігаються, та пакетів. Користувач не має прямого доступу до таблиць і пакетів, його права динамічно перевіряються при виборі даних через механізм представлень та активації операцій через спеціальні механізми виклику. Разом з журналізацією дій та змін цей механізм забезпечує гнучку регламентацію та контроль над діями користувачів системи.
Принцип багаторівневого захисту: організація інформаційної безпеки передбачає створення наступного ряду послідовних рівнів захисту інформаційних ресурсів та персоналу Банку від ймовірних загроз:
організаційно-правовий рівень, який визначає правові та нормативні вимоги та зобов’язання персоналу, користувачів інформаційних ресурсів та контрагентів Банку щодо інформаційної безпеки;
фізичний рівень захисту, який запобігає неавторизованому фізичному доступу, ушкодженню чи вторгненню до службових приміщень Банку з метою несанкціонованого доступу до інформації;
рівень прикладного програмного забезпечення, який відповідає за взаємодію з користувачем інформаційних ресурсів;
рівень системи управління базами даних, який відповідає за зберігання та опрацювання даних;
рівень операційної системи, який відповідає за безпечне та надійне обслуговування прикладного програмного забезпечення та систем управління базами даних;
рівень мережі, який відповідає за взаємодію вузлів інформаційної системи Банку.
В основному для більшої частини веб-додатків основні завдання для реалізації захисту (крім ідентифікованих під час моделювання загроз) завжди одні й ті ж:
аутентифікація
авторизація
конфіденційність
цілісність
4. Як може бути використана функція делегування прав і написання блоку авторизації?
Делегування прав та написання блоку авторизації дозволяє ефективно мінімізувати небезпеку доступу до критичних ресурсів системи.
Адміністративні права можна делегувати на досить детальному рівні. Одній групі можна надати право на скидання пароля, інший - на створення і видалення акаунтів. Можна налаштувати успадкування дозволів.
Блок авторизації є необхідним для керування рівнями та засобами доступу до захищеного ресурсу.
ВИСНОВКИ
У ході лабораторної роботи було досліджено основи аналізу вразливостей та етичного хакінгу моделі безпеки ASP.NET.
Було встановлено, що створення будь якого додатку, а особливо додатку, що буде використовуватись у банківській сфері, повинне починатись саме з питань безпеки. Обов’язково потрібно використовувати правила безпечного коду та, за можливістю, вже готові й перевірені безпечні рішення. Не можна виводити на сторінку код, отриманий від користувача, бо завжди є небезпека XSS, перехоплення cookie та відправлення цих даних третім особам. Необхідно будувати багаторівневий захист програмного забезпечення.