SQLi по раніше в строю

Для злому TalkTalk, який призвів до крадіжці особистих даних близько 150 000 користувачів, була використана уразливість, виявлена ще до його народження. Цим методом атаки була SQL ін'єкція (SQLi). У даному вигляді атак хакерів зазвичай вводять шкідливі команди у форми на веб-сайті, щоб змусить базу сайту видати потрібні дані.



Такий метод використовувався для крадіжки персональних даних співробітників Всесвітньої організації охорони здоров'я, викрадення даних Wall Street Journal і злому сайтів американських федеральних агентств.
Це найпростіший спосіб зламати сайт
Це вислів одного з хакерів, відомого під псевдонімом w0rm і відповідального за злом Wall Street Journal. Вторгнення тоді зайняло всього кілька годин.

При всій своїй простоті SQLi в теж час володіє високої ефективності для отримання цифрових даних корпорацій і навіть урядових сайтів.

SQL-ін'єкції стали бичем для епохи Інтернету. Рік за роком вони згадуються як одні з кращих видів уразливості безпеки, відповідальних за незліченні крадіжок даних в Інтернеті.

Джефф Форристал (Jeff Forristal), можливо, самим першим опублікував інструкцію злому і способи захисту сервера Windows NT з допомогою SQL ін'єкцій в журналі для хакерів Phrack. На даний момент Джефф очолює посаду директора з кібербезпеки в BlueBOX Security.



SQL або Structured Query Language — мова програмування, що використовується для управління базами даних. По суті, він застосовується, коли сайт повинен викликати шматок інформації зі своєї бази даних, або обробити її або представити користувачеві. Але Форристал прийшов до висновку, що введення певних команд змусить сервер показати інформацію, яка на ньому зберігається.
Люди можуть комбінувати SQL команди.
У номері Phrack за грудні 1998 року Форристэл записав про серії проблем з версією Microsoft SQL server. Коли колега Форристэла повідомив про це компанії Microsoft,
Їх відповідь була вельми забавним
ви можете прочитати це не несе жодної загрози, тому не варто хвилюватися і приймати поспішні заходи, щоб це зупинити.
Через більш ніж 15 років після того, як дана уразливість була публічно описана, SQLi неодноразово займав перше місце в Топ-10 вразливостей від OWASP, що виходили раз на три роки. Open Web Application Security Project (OWASP) -некомерційна організація, що відслідковує різні загрози, з якими стикаються веб-сайти.



SQL ін'єкції по колишньому залишаються ризиком номер один для безлічі веб-проектів.
Коли ви переходите на веб-сторінці, то виконуєте запит, який аналізується і після цього вам надаються дані у відповідності з запитом .
Дрібний приклад коли додаток використовує ненадійні дані в побудові подальшого виклику вразливою SQL:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 

Точно також сліпа довіра з боку додатка до платформ може призвести до вразливим запитам.
Наприклад, Hibernate Query Language (HQL):
Query HQLQuery = session.createQuery(“accounts FROM WHERE custID='“ + request.getParameter("id") + "'");

В обох випадках зловмисник модифікує значення параметра «id» в браузері, щоб відправити: 'or '1'='1.
Наприклад:
http://example.com/app/accountView?id=' or '1'='1

Це змінює сенс в обох запитах, що змушує видати всі записи з таблиці акаунтів. Більш небезпечні атаки можуть змінювати дані або навіть викликати збережені процедури.

Разова атака можемо надати одну частину або розділ інформації, а це означає, що злочинцю необхідно буде повторити такого роду запити поки він не отримає всі дані з бази даних. Природно подібний підхід займає багато часу. Таким чином хакери можуть використовувати інструменти, що автоматизують цей процес, виконуючи запити замість нього. Досить популярним інструментом для скрипт-кідді став Havij, бо він добре оптимізований для Windows і має зручний GUI (графічний інтерфейс користувача). Інша частина використовує сканер SQLMAP, випущений в 2006 році. Але більш стрімко SQLMAP став розвиватися тільки тоді, коли в роботу над ним включилися Мирослав Штампар — розробник з Хорватії і Бернардо Дамеле — консультант з ІБ з Італії. Цей сканер подібно боту пошукової системи шукає форми для введення тексту на веб-сторінці і являє форми з даними, які могли б викликати синтаксичну помилку MySQL.

Приклад того, як Трой Хант (Troy Hunt), засновник haveibeenpwned.com, вчить свого сина використовувати SQLi з допомогою Havij.


Пошук жертви нападу також просто автоматизувати. Як правило зловмисники використовують популярний пошуковик Google для пошуку URL адрес, які зв'язуються з скриптами вразливими до SQLi. У нападника існують скрипти, автоматично перевіряючи всі URL на предмет уразливості. Цей процес настільки простий, що йому можна навчити навіть дитини. Також існує досить навчальних посібників на YouTube про те, як вчинити напад SQLi.



Але існують готові рішення, щоб зупинити атаки SQLi і вони можуть бути розгорнуті розробниками сайтів для уникнення витоку споживчих або корпоративних даних. Ці рішення існують протягом багатьох років.

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

Підготовлені запити використовуються для виконання тих же (або аналогічних) SQL-запитів неодноразово з високою ефективністю.

Підготовлені запити в основному працюють так:
1. Підготовка: шаблон SQL-запиту створюється і відправляється в базу даних. Деякі значення не вказуються, називаються параметрами і маркуються "?". Приклад: INSERT INTO MyGuests VALUES(?, ?, ?)
2. Базі даних розбирає, збирає і виконує оптимізацію запитів на шаблоні SQL-запиту і зберігає результат без його виконання.
3. Виконання: Пізніше додаток пов'язує значення з параметрами і база даних виконує запит. Додаток може виконати запит стільки разів, скільки це буде потрібно з різними значеннями.

Порівняно з виконанням безпосередніх SQL-запитів, підготовлених запитів є три основні переваги:

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

<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDB";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}

// prepare and bind
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname, email) VALUES (?, ?, ?)");
$stmt->bind_param("sss", $firstname, $lastname, $e);

// set parameters and execute
$firstname = "John";
$lastname = "Doe";
$email = "john@example.com";
$stmt- > execute();

$firstname = "Mary";
$lastname = "Мое";
$email = "mary@example.com";
$stmt- > execute();

$firstname = "Julie";
$lastname = "Dooley";
$email = "julie@example.com";
$stmt- > execute();

echo "New records created successfully";

$stmt->close();
$conn->close();
?>

В даному SQL знак питання (?) виставлений там, де ми хочемо помістити integer, string, double або blob значення.

"INSERT INTO MyGuests (firstname, lastname, email) VALUES (?, ?, ?)"

Тепер давайте подивіться на функцію bind_param ():

$stmt->bind_param("sss", $firstname, $lastname, $e);

Ця функція пов'язує параметри з SQL-запитом і каже базі даних які потрібно ввести параметри. Аргумент «sss» обмежує тип даних, які можуть бути задані для перерахованих параметрів.

Аргумент може бути одним із чотирьох типів:

i — integer
s — double
s — string
b — BLOB

Розповідаючи MySQL який тип даних очікувати, ми мінімізуємо ризик ін'єкцій SQL.

Підготовлення запиту в PDO

<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDBPDO";

try {
$conn = new PDO("mysql:host=$servername;dbname=$dbname", $username, $password);
// set the PDO error mode to exception
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// prepare sql and bind parameters
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname, email) 
VALUES (:firstname, :lastname, email)");
$stmt->bindParam(':firstname', $firstname);
$stmt->bindParam(':lastname', $lastname);
$stmt->bindParam ('email', $e);

// insert a row
$firstname = "John";
$lastname = "Doe";
$email = "john@example.com";
$stmt- > execute();

// insert another row
$firstname = "Mary";
$lastname = "Мое";
$email = "mary@example.com";
$stmt- > execute();

// insert another row
$firstname = "Julie";
$lastname = "Dooley";
$email = "julie@example.com";
$stmt- > execute();

echo "New records created successfully";
}
catch(PDOException $e)
{
echo "Error: " . $e->getMessage();
}
$conn = null;
?>


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

Якщо SQLI настільки проста, що навіть дитина може це зробити. І рішення досить просте. Але чому тоді атаки на основі SQLI все ще успішні?

Будь-який серйозний програміст повинен знати про SQLi, але по факту знайти дійсно хорошого програміста на зарубіжному ринку — завдання не з легких. Цьому є підтвердження з особистих досвіду. Мій знайомий майже рік тому пішов працювати в закордонний проект. Він вважав себе досить посереднім програмістом (до речі, точно так само вважали і його знайомі іт-фахівці, екс-колеги). Але він був приємно здивований тим, що на своєму новому місці роботи виявився кращим. Він досі на своєму проекті вважається висококваліфікованим фахівцем. Саме по-цьому зарубіжні компанії наймають посередніх програмістів, навіть якщо ті не мають уявлення про варіанти пом'якшення базових видів вразливості.

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

В кінцевому підсумку відповідальність за безпеку цих сайтів і дані, які вони містять, зводяться до самих веб-розробникам.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.