Атака SQL Injection, Microsoft Docs

Атака типу SQL Injection - це атака, при якій проводиться вставка шкідливого коду в рядки, що потім передаються в екземпляр SQL Server для синтаксичного аналізу та виконання. Будь-яка процедура, яка створює інструкції SQL, повинна розглядатися на предмет вразливості до вставки небезпечного коду, оскільки SQL Server виконує всі синтаксично правильні запити, що отримуються. Навіть параметризовані дані можуть бути предметом маніпуляцій досвідченого зловмисника.

Основна форма атаки SQL Injection полягає в прямій вставці коду в вхідні змінні користувача, які об'єднуються з командами SQL і виконуються. Менш явна атака впроваджує небезпечний код у рядки, призначені для зберігання таблиці або у вигляді метаданих. Коли згодом збережені рядки поєднуються з динамічною командою SQL, відбувається виконання небезпечного коду.

Наступний сценарій показує просту атаку SQL Injection. Сценарій формує SQL-запит, виконуючи об'єднання жорстко запрограмованих рядків із рядком, введеним користувачем:

Користувачеві виводиться запит на введення назви міста. Якщо користувач вводить Redmond, запит, побудований за допомогою сценарію, виглядає приблизно так:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

Припустимо, однак, що користувач вводить таке:

Redmond'; drop table OrdersTable--

У цьому випадку запит, побудований сценарієм, буде наступним:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

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

Перевірка достовірності всіх даних, що вводяться

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

Не робіть жодних припущень про розмір, тип або вміст даних, отриманих програмою. Наприклад, рекомендується оцінити таке.

Як додаток поводитиметься, якщо користувач помилково або за злим наміром вставить MPEG-файл розміром 10 МБ там, де програма очікує введення поштового індексу?

Як поводитиметься програма, якщо в текстове поле буде впроваджено інструкцію DROP TABLE?

Перевірте розмір і тип даних, що вводяться, і встановіть відповідні обмеження. Це допоможе запобігти навмисному переповненню буфера.

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

Ніколи не створюйте інструкції Transact-SQL безпосередньо з даних, які користувач вводить.

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

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

Впровадьте багатоетапну перевірку достовірності. Запобіжні заходи, вжиті проти випадкових користувачів-зловмисників,можуть бути неефективними проти організаторів навмисних атак. Рекомендується перевіряти дані, що вводяться через інтерфейс користувача, і далі у всіх наступних точках перетину кордонів довіреної зони.

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

Ніколи не об'єднуйте дані, що були введені користувачем, без перевірки. Об'єднання рядків є основною точкою входу для використання сценарію.

Не допускайте використання в полях наступних рядків, з яких можуть бути створені імена файлів: AUX, CLOCK$, COM1-COM8, CON, CONFIG$, LPT1-LPT8, NUL та PRN.

По можливості відхиляйте дані, що містять такі символи:

---