CW7 - Githubissues

Запитання 1

Опишіть ПЗ, в якому знайдено вразливість:

назва ПЗ, URL-посилання в інтернеті (знайти через пошукову систему):

Sports-Club-Management-System, https://github.com/shreyansh225/Sports-Club-Management-System

призначення ПЗ та приклади споживачів, які можуть бути зацікавлені у використанні ПЗ:

Система управління спортивним клубом — це процес, за допомогою якого записи про учасників безпосередньо зберігаються, і адміністратор може отримати до них інтерактивний доступ у режимі реального часу без посередницької служби. Система керування спортивним клубом – це процес зберігання інформації про членів, включаючи стан здоров’я, платіжні відомості, режими вправ тощо, які прийняли участь у спортивному клубі. З моменту появи Всесвітньої павутини власники прагнули зберігати дані своїх користувачів у цифровій системі для легкого доступу та з’ясування кожної деталі, коли це необхідно.

Запитання 2

Опишіть знайдену вразливість , переклавшу на українську розділ Description.

У Sports Club Management System 119 виявлено вразливість, класифіковану як критичну. Вона впливає на невідому частину файлу admin/make_payments.php. Маніпуляції з аргументом m_id/plan призводять до впровадження sql. Ініціювати атаку можна віддалено. Експлойт був відкритий для громадськості та може бути використаний. Цій уразливості присвоєно ідентифікатор VDB-213789.

Запитання 3:

Наведіть фрагменти прикладів уразливого програмного коду, розглянувши розділ References to Advisories, Solutions, and Tools.

У admin/makePayments.php у рядку 119 інформація, введена користувачем, надсилається в submit Payments.php, слідкуйте за кодом, і ми бачимо, що m, введений користувачем_ Ідентифікатор, присвоєно $memID. Без будь-якої фільтрації він безпосередньо вставляється в базу даних для запиту, а результати запиту повертаються, що спричиняє вразливості SQL-ін’єкції

Ручна перевірка

Запитання 4:

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

1. Вступ

У сучасному світі повсюдних обчислень кожна людина залишається підключеною до Інтернету. У цих У ситуаціях веб-безпека є дуже необхідною, і це складна частина веб-додатків (A. Кізун і Ернст 2009). Для захисту веб-додатків використовується ряд методів. The Найпоширенішим способом є процес автентифікації за допомогою імені користувача та пароля. Один з головних Проблемами в процесі автентифікації є перевірка підтвердження вхідних даних (Boyd and Keromytis 2004; K. Вей і Котарі 2006; Р. Езумалай 2009). У безпеці веб-додатків є кілька основних напрямків наприклад, SQL-ін’єкція та переповнення буфера, які можуть порушити безпеку веб-програми (Geer 2008). SQL-ін’єкція є надто вразливою, щоб обійти багато традиційних рівнів безпеки, наприклад Брандмауер, шифрування та традиційні системи виявлення вторгнень (R. Ezumalai 2009). Також може обходити механізми аутентифікації та авторизації бази даних (A. Kamra and Guy 2008) SQL-ін’єкцію можна використовувати не лише для порушення безпеки шляхом перегляду приватних даних людей, але також може використовуватися для обходу автентифікації користувача, що є великою вадою в Інтернеті програми. Основною проблемою вразливості веб-додатків є впровадження SQL. Це має бути вважають, що SQL-ін’єкція є легкою атакою, і кожен розробник може легко виконати SQL-ін’єкцію що є найбільш тривожним аспектом впровадження SQL (R. Ezumalai 2009). Сторінка входу - це найскладніша веб-програма, яка дозволяє користувачам входити в бази даних після його автентифікації. На цій сторінці користувач вказує свою особу, наприклад ім’я користувача та пароль. Можливо, є деякі перевірки недійсних введених даних, які можуть обійти процес автентифікації за допомогою певного механізму, наприклад SQL-ін’єкції (Palmer 2007). Зазвичай веб-додатки мають трирівневу архітектуру: рівень додатків на стороні користувача, Середній рівень, який перетворює запити користувача у формат SQL, і сервер бази даних який зберігає дані користувача, а також таблицю автентифікації користувача. Щоразу, коли користувач захоче увійти у веб-базу даних через прикладний рівень, користувач вводить свою автентифікаційну інформацію з a форму входу, як показано на малюнку 1.

Рисунок 1: Проста форма входу

Сервер середнього рівня перетворить вхідні значення імені користувача та пароля з введених користувачами у формат, як показано на малюнку 2. Рисунок 2: Приклад простого SQL-запиту

Якщо результат запиту є істинним, тоді користувач автентифікується, інакше – відмовлено. Але, є деякі шкідливі атаки, які можуть ввести в оману сервер бази даних шляхом введення шкідливого коду через SQL injection, який завжди повертає справжні результати запиту автентифікації. Наприклад, входить хакер вираз у полі «Ім’я користувача», наприклад '' ' АБО 1=1 – – ' ''. Отже, середній рівень перетворить його на SQL формат запиту, як показано на малюнку 3. Це обманює сервер автентифікації.

Рисунок 3: Приклад SQL-запиту з порушенням введення

Аналізуючи наведений вище запит, результат завжди вірний для змінної Query_result. Це тому, що у запиті використано шкідливий код. Тут, у цьому запиті позначка ( ' ) повідомляє аналізатору SQL, що рядок імені користувача завершено, і оператор «АБО 1=1» додається до оператора, який завжди призводить до істини. Знак (– –) є знаком коментаря в SQL, який повідомляє синтаксичному аналізатору, що оператор є завершено, і пароль не перевірятиметься. Отже, результат усього запиту поверне значення true для Змінна Query_result, яка автентифікує користувача без перевірки пароля. Було запропоновано багато методів для керування впровадженням SQL, наприклад, динамічний інструменти моніторингу (Su and Wassermann 2006; Halfond and Orso 2008; Pietraszek and Berghe 2005). Кожна з цих технік має ряд переваг і недоліків. Основні проблеми з цим методи полягають або у значних модифікаціях коду, або потребують значного додаткового часу. У цьому документі представлено новий метод захисту бази даних від впровадження SQL, який використовує збережені процедури СУБД для аутентифікації користувачів у базі даних. Ось хеш-значення для ім’я користувача та пароль, а також ім’я користувача та пароль використовуються для автентифікації. Ці хеш значення для імені користувача та пароля генеруються автоматично, коли користувач входить до бази даних. А користувач автентифікується за допомогою імені користувача, пароля та хеш-значень для імені користувача та пароля. The накладний час підходу занадто малий і становить 1,3 мс. Стаття має таку структуру: у розділі 2 розглядаються визначення та передумови. Розділ 3 описує суміжну роботу. Розділ 4 зосереджений на запропонованій техніці автентифікації, а розділ 5 про архітектуру запропонованої техніки. Розділ 6 обговорює методологію. Розділ 7 оцінює і показує результати. Нарешті, розділ 8 завершує виконану роботу.

3. Пов’язана робота

Були запропоновані різні техніки для контролю атак SQL-ін’єкцій, наприклад, AMNESIA (Аналіз і моніторинг для нейтралізації атак SQL-ін’єкцій) (Halfond and Orso 2005). AMNESIA , автори використовують перевірку під час виконання запиту та оголошують його дійсним або шкідливим. AMNESIA перевіряє запит на різних етапах. На першому кроці він визначає «гарячу точку». Гарячі точки є код програми, який надсилає SQL-запит до бази даних. По-друге, це формує модель для законного запиту в форма NDFA (недетерміновані кінцеві автомати). Нарешті, коли надходить запит, він перевіряє запит за допомогою NDFA та оголошує його законним або шкідливим.

MeiJunjin (MeiJunjin) використовує підхід для виявлення вразливостей впровадження SQL. Вищезгаданий автор використовував статичні, динамічні та автоматичні методи тестування для виявлення Уразливості ін'єкції SQL. Цей підхід відстежує запити користувачів до вразливого місця. Buehrer та інші (G.T. Buehrer and Sivilotti 2005) використовують дерево розбору, структуру даних, для перевірка запиту. У цій методиці автори використовували дерево аналізу як модель і кожен запит вхід до бази даних перевіряється за цим деревом. Після перевірки за допомогою дерева аналізу запит є будь-яким визнані дійсними або зловмисними. Підхід, заснований на специфікаціях, був запропонований Kemalis et al (Kemalis and Tzouramanis 2008). У цій техніці вони визначають модель для операторів SQL. Модель базується на наборі правил. Інструкції SQL перехоплюються в модель. Після лексичного розбору та синтаксичної перевірки запит оголошує його дійсним або недійсним. Він зберігає файл журналу всього процесу, який буде сприяти адміністратору. Вільям та інші (Halfond and Orso 2005) запропонували механізм, за допомогою якого вони запобігають SQL впорскування за допомогою статичного аналізу. У цьому механізмі вони створюють NDFA (Non-Deterministic Finite Automata) гарячої точки та виконує пошук у глибину для проходження гарячих точок. Вони дізнаються підозрілі заяви з використанням цих NDFA. Він генерує тривогу, коли виявлено підозрілу активність. Підхід, заснований на аномаліях, був представлений Cava та ін. (M. Cova and Vigna 2007) для виявлення волі веб-додатків. Вони використовують «Swaddler» для аналізу внутрішнього стану веб-додатків. Вони викликають Swaddler для пошуку зв'язку критичних точок програми. Виявивши внутрішній стан і зв’язок між критичними точками, Swaddler здатний ідентифікувати Ezumalai та інші (R. Ezumalai 2009) використовували підхід на основі підписів для захисту SQLinjection. У цьому підході вони використовували три модулі для виявлення проблем безпеки. Модуль моніторингу, який приймає вхідні дані від веб-програми та надсилає їх до модуля аналізу. Модуль аналізу, який знаходить гарячі точки з програми, використовує алгоритм Гіршберга (Hirschberg 1975). Алгоритм Гіршберга — це алгоритм порівняння рядків, який працює за правилом «розділяй і володарюй». Він зберігає всі ключові слова в модулі специфікацій.

oleksandrblazhko / ai182-keosak

CW7 #29