Чи опора на параметризовані запити є єдиним способом захисту від введення SQL?

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

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

1. Жоден клієнт / додаток не мав прямого доступу до таблиць баз даних.
2. Усі звернення до всіх таблиць проводилися через представлення даних (а всі оновлення базових таблиць здійснювались через тригери).
3. Усі елементи даних мали вказаний домен.
4. Жоден елемент даних не був допущений до зведення нанівець - це мало наслідки, які зусилля DBA моментували зубами; але був примусовий.
5. Ролі та дозволи були встановлені належним чином - наприклад, обмежена роль для надання лише поглядам права на зміну даних.

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

EDIT

Наголос на питанні незначно змінився, з огляду на отримані початкові відповіді. Основне питання не змінилося.

EDIT2

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

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

http://database-programmer.blogspot.com

http://thehelsinkideclaration.blogspot.com

Принципові особливості, які я взяв із цих джерел:

1. Обширний словник даних у поєднанні з широким словником даних про безпеку
2. Генерація тригерів, запитів та обмежень із словника даних
3. Мінімізуйте код та максимізуйте дані

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

Збережені програми не захищають автоматично від ін'єкцій. Як що до цього

CREATE PROC proc
  @id VARCHAR(5)
AS
BEGIN
  EXEC("SELECT * FROM Client WHERE ClientId = " + @id);
END

Використання параметризованих запитів захистить вас від ін'єкцій, незалежно від того, чи є вони в документах чи ні.

Тож чи є набір таких (примусових) правил, як ця, є відповідною альтернативою збереженим процедурам для запобігання атакам ін'єкції SQL? Якщо ні, то чому б і ні?

Ні, тому що вони наносять досить велике покарання розробникам. Розбивка на предмет:

1. Жоден клієнт / додаток не мав прямого доступу до таблиць баз даних.

Використовуйте ролі. Клієнти повинні мати доступ до БД тільки через обмежену роль, яка має лише доступ SELECT, INSERT, UPDATE та DELETE до тих таблиць (і рядків, де це можливо), до яких їй потрібен доступ. Якщо ви хочете переконатися, що жоден клієнт не може спамувати або видаляти всі записи, використовуйте API для зміни даних.

2. Усі звернення до всіх таблиць проходили через представлення даних.

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

3. У всіх елементах даних був вказаний домен.

Може бути багато роботи для підтримання, і, ймовірно, слід нормалізувати в окрему таблицю.

4. Жоден елемент даних не був дозволений для зведення нанівець - це мало наслідки, які змушували зусилля АПУ прицілювати зуби; але був примусовий.

Це просто неправильно. Якщо розробники не в змозі впоратися, NULLу вас є великі проблеми.

Чи можна захистити базу даних від таких атак спеціальними заходами для бази даних?

Вам не потрібні збережені процедури, просто використовуйте параметризовані запити з функцією, яка уникає аргументів, таких як pg_query_params . Звичайно, якщо у вашій базі даних є можливість запису у всьому світі або роль клієнта має повний доступ до всього, ви все одно накрутитеся. Хтось просто повинен підійти і зрозуміти, що робить клієнт, а потім готувати клієнта за п’ять хвилин, що знищує (або ще гірше, отруєння) вашої БД.

Я не впевнений, що ваші правила вас повністю захищають.

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

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

Пам'ятайте також, що справа не лише в оновленні чи видаленні даних. Частина вразливості за допомогою інжекції SQL - це збирання інформації, і для цього вам не байдуже, чи були дані передані назад через перегляд vCustomers або нижчу таблицю клієнтів. Ви можете захистили себе від деяких слабких сторін , але не всі. Аналогічно, якщо оновлення може бути здійснено клієнтом, навіть якщо через тригери, тоді SQL можна записати для запуску тригерів та оновлення.

(Що стосується того, що всі оновлення здійснюються через тригери, я скажу дві речі: (1) коли я прочитав це, я трохи захворів у роті, і (б) вам не подобаються збережені процедури, оскільки вони ' re "менш рентабельний; менш перевірений; сильно пов'язаний; і заблокував систему в одного постачальника", але ви використовуєте тригери, про які в основному можна сказати одне і те ж.)

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

Інша річ у тому, що ви також додаєте складності та (як і накладні витрати), складність, як правило, призводить до появи дірок, які можна використовувати.

Я не кажу, що такий набір правил створити не вдалося - більше, чому ви б турбувались? Вони здаються більш громіздкими і менш надійними, ніж просто йти з широко прийнятими методами запобігання подібному нападу.