search

oleksandrblazhko / ai-192-chubarko

0 stars 0 forks source link

CW7 #19

Closed TekiMeki closed 10 months ago

TekiMeki commented 10 months ago

Варіант 23

Запитання №1

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

Запитання №2

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

Опис

Вразливість була знайдена у centreon. Її оголошено критичною. Ця уразливість впливає на невідомий код файлу formContactGroup.php компонента Contact Groups Form. Маніпуляції з аргументом cg_id призводять до SQL ін'єкції. Атака може бути ініційована дистанційно. Назва патча 293b10628f7d9f83c6c82c78cf637cbe9b907369. Щоб вирішити цю проблему, рекомендується застосувати патч. VDB-212794 — це ідентифікатор, призначений цій вразливості.

Запитання № 3

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

$DBRESULT = $pearDB->query("SELECT * FROM `contactgroup` WHERE `cg_id` = '" . $cg_id . "' LIMIT 1");
    $statement = $pearDB->prepare("SELECT * FROM `contactgroup` WHERE `cg_id` = :cg_id LIMIT 1");
    $statement->bindValue(':cg_id', (int) $cg_id, \PDO::PARAM_INT);
    $statement->execute();

    /*
     * Set base value
     */
    $cg = array_map("myDecode", $DBRESULT->fetchRow());
    $cg = array_map("myDecode", $statement->fetch(\PDO::FETCH_ASSOC));
}

$attrsText = array("size" => "30");

Запитання № 4

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

Веб-додатки надзвичайно популярні сьогодні, тому що вони всюдисущі та їх можна легко підтримувати та оновлювати. Користувачі отримують доступ до інтерфейсу через веб-браузер і надсилають запити на веб-сервер, який, у свою чергу, перетворює ці запити на команди SQL бази даних і, використовуючи результати цих команд, генерує відповідь, яка надсилається назад у браузер для остаточного представлення користувача. Основна проблема полягає в тому, що веб-додатки часто небезпечні. Насправді розробники веб-додатків зазвичай не спеціалізуються на безпеці, і звичайні обмеження щодо часу виходу на ринок спрямовують зусилля на задоволення вимог користувача, через що аспектами безпеки легко нехтувати. Ін’єкція SQL є особливо небезпечною загрозою, яка використовує вразливості прикладного рівня, властиві веб-додаткам. Замість атаки на екземпляри, такі як веб-сервери чи операційні системи, метою SQL-ін’єкції є атака на RDBMS, що працюють як серверні системи для веб-серверів, через веб-додатки [1]. Кожен веб-додаток, що використовує реляційну базу даних, теоретично може стати об’єктом атак SQL-ін’єкцій. Таким чином, у разі успіху атаки з впровадженням SQL можуть призвести до викриття та серйозного впливу на найцінніші інформаційні активи корпорацій. Ці атаки можуть у гіршому випадку призвести до повного знищення схеми бази даних, що, у свою чергу, може вплинути на здатність корпорації вести бізнес [2]. Сторінка входу - це найскладніший веб-додаток, який дозволяє користувачам входити в базу даних після їх автентифікації. На цій сторінці користувачі вказують свою особу, наприклад ім’я користувача та пароль.Досвідчений зловмисник може скомпрометувати ім’я користувача та пароль, запускаючи онлайн- та офлайн-атаки вгадування. Веб-програми, як правило, мають трирівневу модель: додаток (передній енд), середній рівень (протокол) і бекенд (база даних), як показано на малюнку 1. Якщо користувач хоче отримати доступ до бази даних із віддаленого місця, він повинен увійти в систему через веб-сайт, використовуючи ім’я користувача та пароль. На середньому рівні генерується SQL-запит із заданими вхідними даними. Сервер перевіряє ім'я користувача та пароль, якщо вони збігаються, користувачеві буде дозволено доступ до бази даних. Сторінка входу є найскладнішою у веб-додатку, яка дозволяє користувачам отримати доступ до бази даних після завершення процесу автентифікації. На цій сторінці користувач вказує свою особу, наприклад ім’я користувача та пароль. Можуть бути деякі перевірки недійсних вхідних даних, які можуть обійти процес автентифікації за допомогою певного механізму, наприклад SQL-ін’єкції [3]. Якщо ім’я користувача та пароль визначено користувачем, метод вбудовує надіслані облікові дані в запит. Наприклад, якщо користувач надсилає ім’я користувача та пароль як «XYZ» і «111», тоді запит матиме такий вигляд: Query_result = «SELECT from User_Credentials WHERE username = 'XYZ' and password = '111'” Веб-сайт, який використовує цей сервлет буде вразливим до SQLIA: наприклад, якщо користувач введе «'OR 1=1 --» і «», замість «XYZ» і «111», результат запиту: Query_result = «SELECT from User_Credentials WHERE ім'я користувача = ''OR 1 = 1 --'AND пароль = ''” Аналізуючи наведений вище запит, результат завжди вірний для змінної Query_result.Це тому, що в запиті використано шкідливий код. Тут у цьому запиті позначка (‘) повідомляє аналізатору SQL, що рядок імені користувача завершено, а оператор «АБО 1=1» додається до оператора, результатом якого завжди є true. Позначка (– –) є позначкою коментаря в SQL, яка повідомляє синтаксичному аналізатору, що оператор завершено і пароль не перевірятиметься. Отже, результат усього запиту поверне значення true для змінної Query_result, яка автентифікує користувача без перевірки пароля. Стаття має таку структуру: Розділ 2 обговорює передумови. Розділ 3 описує пов’язану роботу. Розділ 4 присвячено запропонованому методу автентифікації користувача, а розділ 5 обговорює реалізацію та тестування. Нарешті, розділ 6 завершує виконану роботу.

oleksandrblazhko commented 10 months ago

5 балів