У деяких випадках, СКЛ ін'єкція можлива навіть в параметрі, який перетворюється методами mod_rewrite модуля apache, до GET параметру скрипта.
Наприклад, скрипти типу /news/127.html перетворюються до /news/news.php?id=127 наступним правилом: RewriteRule ^ / news / (. *) \. Html $ "/news/news.php?id=$1"
Це дозволить передати зловмисні значення параметра скрипту. Так, наприклад /news/128-1.html
коротко про захист.
Для захисту від усього вищесказаного досить дотримуватися декількох простих правил.
1) для цілих і дробових величин, перед їх використанням в запиті досить привести величину до потрібного типу.
Замість цього можна вставити систему стеження за тестуванням на SQL ін'єкцію.
// пишемо в лог про спробу
2) для строкових параметрів, які не використовуються в like, regexp і тд, екрануючи лапки.
3) в рядках, які передбачається використовувати всередині like, regexp і тд, необхідно так само заекранувати спеціальні символи, що застосовуються в цих операторах, якщо це необхідно. В іншому випадку, можна задокументувати використання цих символів.
Цей документ не охоплює базовий SQL синтаксис або SQL ін'єкції. Передбачається, що читач вже має відмінне розуміння предмета. Цей документ буде сфокусований на просунутих техніках, які можуть бути використані в атаках на web-додатки використовують Microsoft SQL Server. Ці техніки демонструють як атакуючий може використовувати SQL ін'єкції для того щоб видаляти з бази даних минаючи брандмауер і проникати у внутрішню мережу. Цей документ покликаний навчити професіоналів інформаційної безпеки потенційно небезпечним ефектів SQL ін'єкцій, які можуть статися у вашій організації.
Web-додатки стають більш захищеними, оскільки зростає кількість повідомлень про атаки, таких як SQL ін'єкції. Проте, у великих і комплексних додатках, одна помилка може стати результатом компрометації всієї системи. Безліч розробників і адміністраторів web-додатків можуть мати помилкове відчуття безпеки, оскільки вони використовують процедури, або приховують повідомлення про помилки повертаються в вікно браузера. Це дає підставу вірити в те, що вразливістю неможливо скористатися.
Хоча в цьому документі ми обговорюємо Microsoft SQL Server, це не говорить про те, що цей продукт менш захищений, ніж інші платформи, такі як Oracle або IBM DB2. SQL ін'єкції це не конкретна уразливість Microsoft SQL Server це також проблема баз даних в цілому. Можливо, велика проблема Microsoft SQL Server це його гнучкість. Завдяки цій гнучкості відкриваються нові можливості для проведення атак класу SQL Injection. Мета цього документа показати, що кожен раз, коли адміністратор або розробник допускає виконання довільного SQL запиту, яку атакують система відкрита для повного захоплення. Це не є показником того, що продукт Microsoft SQL Server вразливим в цілому.
Виявлення SQL ін'єкцій
При спробі використання SQL ін'єкцій в додатках, атакуючий потребує методі визначення дійсно відбулося впровадження довільного SQL запиту. Так само існує необхідність в методі отримання результатів. Для цього можуть бути використані дві вбудовані функції SQL сервера. Функції OPENROWSET і OPENDATASOURCE призначені для відкриття віддаленого джерела даних. Цими параметрами, щоб відкриття з'єднання за допомогою провайдера OLEDB. Функція OPENROWSET буде використана в усіх прикладах, але з тими ж результатами може бути використана функція OPENDATASOURCE.
Цей вислів повертає всі рядки таблиці table1 з віддаленого джерела даних:
'Select * from table1')
параметри:
(1) Ім'я провайдера OLEDB
(2) Рядок підключення (може бути в форматі необхідному OLEDB або ODBC)
(3) Вираз SQL
'Select * from table')
'Select * from table')
В процесі SQL ін'єкції атакуючий може визначити, виконався чи SQL запит. Якщо SQL запит успішно виконаний, атакований сервер спробує встановити вихідні повідомлення з комп'ютером атакуючого на вказаний порт. Це що виходить SQL з'єднання в більшості випадків не буде блоковано брандмауером, так як використовується 80-й порт.
Ця техніка дозволяє атакуючому дізнатися виконався чи SQL запит, навіть якщо повідомлення про помилки і результати запиту не були виведені у вікно браузера.
Отримання результатів з SQL ін'єкцій
Функції OPENROWSET і OPENDATASOURCE найбільш часто використовуються для вилучення необхідних даних. Вони можуть бути також використані для переміщення даних на віддалений SQL сервер. Функція OPENROWSET може бути використана не тільки для виконання запиту SELECT, але також для виконання INSERT і DELETE в зовнішніх джерелах даних. Обробка даних з віддаленого джерела не є загальним випадком і працює, тільки якщо OLEDB провайдер підтримує цю можливість. Провайдер SQLOLEDB володіє такими функціональними можливостями.
Нижче наведено приклад приміщення даних у зовнішній джерело даних:
'Select * from table1')
select * from table2
У цьому прикладі всі рядки в таблиці table2 локального SQL сервера будуть додані в таблицю table1 знаходиться на віддаленому сервері. Для успішного виконання запиту необхідно щоб обидві таблиці мали схожу структуру.
Як ми дізналися в попередньому абзаці, віддалені джерела даних можуть бути перенаправлені на будь-який з вибору сервер атакуючого.
Атакуючий може змінити запит вище для з'єднання з віддаленим джерелом даних, таким як копія Microsoft SQL Server запущених на машині атакуючого.
'Select * from table1'
select * from table2
Для того щоб успішно вставити дані, атакуючий повинен створити таблицю table1 з тими ж стовпцями і типами даних як в таблиці table2. Ця інформація може бути визначена, використовуючи цей же трюк для системних таблиць. Це спрацює, тому що структура системних таблиць заздалегідь відома. Атакуючий повинен почати з створення таблиць зі структурою ідентичною системних таблиць sysdatabases, sysobjects і syscolumns. Потім щоб витягти необхідну інформацію повинні бути виконані наступні SQL запити:
'Select * from _sysdatabases')
select * from master.dbo.sysdatabases
'Select * from _sysobjects')