Чому механізм запобігання ін'єкцій SQL еволюціонував у напрямку використання параметризованих запитів?

Як я це бачу, атаки ін'єкцій SQL можна запобігти:

1. Ретельно перевіряйте, фільтруючи, кодуючи вхід (перед вставкою в SQL)
2. Використання підготовлених операторів / параметризованих запитів

Я гадаю, що у кожного є плюси і мінуси, але чому номер 2 зняв і став вважатися більш-менш фактичним способом запобігання ін'єкційним атакам? Це просто безпечніше і менш схильне до помилок чи були інші фактори?

Як я розумію, якщо правильно використовувати # 1 і дотримуватися всіх застережень, він може бути таким же ефективним, як і №2.

Санітизація, фільтрування та кодування

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

Параметризовані запити проти бібліотеки кодування

Є відповіді, де поняття parameterized queriesта до encoding librariesних трактуються взаємозамінно. Виправте мене, якщо я помиляюся, але я маю враження, що вони різні.

Я розумію, що encoding librariesнезалежно від того, наскільки вони хороші, вони завжди можуть змінити SQL "Програму", оскільки вони вносять зміни в сам SQL, перш ніж він буде відправлений в RDBMS.

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

Кодування бібліотеки

  data -> (encoding library)
                  |
                  v
SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement

Параметризований запит

                                               data
                                                 |
                                                 v
SQL -> RDBMS (query execution plan defined) -> data -> execute statement

Історичне значення

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

Проблема полягає в тому, що №1 вимагає ефективного розбору та інтерпретації всього варіанту SQL, проти якого ви працюєте, щоб ви знали, чи робить він щось, чого не повинен. І постійно оновлюйте цей код під час оновлення бази даних. Скрізь, де ви приймаєте вклад для своїх запитів. І не накручуйте.

Так, так, подібні речі зупиняли б нападки ін'єкцій SQL, але реалізувати це абсурдно дорожче.

Тому що варіант 1 не є рішенням. Екранування та фільтрування означає відхилення або видалення недійсного введення. Але будь-які дані можуть бути дійсними. Наприклад, апостроф - дійсний символ у назві "О'Маллей". Перед використанням у SQL його потрібно правильно закодувати, саме це і робить підготовлені оператори.

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

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

List<Integer> list = /* a list of 1, 2, 3 */
String strList = list.toString();   /* to get "[1, 2, 3]" */
strList = /* manipulate strList to become "[1, 2, 5, 3]" */
list = parseList(strList);

Якщо хтось пропонує це зробити, ви правильно відповісте, що це досить смішно, і що потрібно просто зробити:

List<Integer> list = /* ... */;
list.add(5, position=2);

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

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

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

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

Тут є хороша аналогія між макросами у стилі C, які виконують просту заміну тексту, та макросами стилю Lisp, які роблять довільну генерацію коду. За допомогою макросів у стилі C ви можете замінити текст у вихідному коді, а це означає, що у вас є можливість вводити синтаксичні помилки чи оманливу поведінку. За допомогою макросів Lisp ви генеруєте код у формі, в якій компілятор обробляє його (тобто ви повертаєте фактичні структури даних, які обробляє компілятор, а не текст, який читач повинен обробити, перш ніж компілятор зможе дістатись до нього) . З макросом Lisp ви не можете створити щось, що було б помилкою розбору. Наприклад, ви не можете генерувати (нехай ((ab) a .

Навіть за допомогою макросів Lisp ви все одно можете генерувати поганий код, оскільки вам не обов'язково знати про структуру, яка повинна бути там. Наприклад, в Lisp, (нехай ((ab)) a) означає "встановити нову лексичну прив'язку змінної a до значення змінної b, а потім повернути значення a", і (нехай (ab) a) означає "встановити нові лексичні прив'язки змінних a і b і ініціалізувати їх як до нуля, а потім повернути значення a." Вони синтаксично правильні, але вони означають різні речі. Щоб уникнути цього питання, ви можете використовувати більш семантично усвідомлені функції та робити щось на кшталт:

Variable a = new Variable("a");
Variable b = new Variable("b");
Let let = new Let();
let.getBindings().add(new LetBinding(a,b));
let.setBody(a);
return let;

Щось подібне неможливо повернути щось синтаксично недійсне, і набагато важче повернути те, що випадково не те, що ви хотіли.

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

Просто сказали: Вони цього не зробили. Ваша заява:

Чому механізм запобігання ін'єкцій SQL еволюціонував у напрямку використання параметризованих запитів?

є принципово хибним. Параметризовані запити існують набагато довше, ніж SQL Injection, принаймні, широко відомий. Вони, як правило, розроблені як спосіб уникнути стринг-концентації у звичайній програмі LOB (Line of Business) функціональної форми для пошуку. У багатьох - МНОГО - через роки хтось знайшов проблему із безпекою із маніпуляцією з рядком.

Я пам’ятаю, що робив SQL 25 років тому (коли Інтернет НЕ широко використовувався - він тільки починався), і я пам’ятаю, що робив SQL проти IBM DB5 IIRC версії 5 - і вже параметризував запити.

Окрім усіх інших хороших відповідей:

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

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

З точки бази даних SQL зору select * from employees where last_name = 'Smith'і select * from employees where last_name = 'Fisher'явно відрізняються , і тому вимагають окремого розбору, компіляції та оптимізації. Вони також будуть займати окремі слоти в області пам'яті, призначені для зберігання складених операторів. У сильно завантаженій системі з великою кількістю подібних запитів, які мають різні параметри обчислення та накладних витрат на пам'ять, можуть бути істотними.

Згодом використання параметризованих запитів часто дає основні переваги щодо продуктивності.

Зачекайте, але чому?

Варіант 1 означає, що вам доведеться писати санітарні процедури для будь-якого типу введення, тоді як варіант 2 менш схильний до помилок і менше коду для запису / тестування / обслуговування.

Майже напевно "піклуватися про всі застереження" може бути складнішим, ніж ви вважаєте, що це так, і ваша мова (наприклад, Java PreparedStatement) має більше кришки, ніж ви думаєте.

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

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

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

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

Але не всі змінні є рядками. Іноді потрібно замінити ціле число або дату. Вони представлені по-різному для рядків, тому вам потрібні різні методи кодування (знову ж таки, вони повинні бути специфічними для постачальника бази даних), і вам потрібно замінити їх у запиті різними способами.

Тож, можливо, все буде простіше, якби база даних обробляла заміну і для вас - вона вже знає, на які типи очікує запит, і як безпечно кодувати дані, і як безпечно замінити їх у ваш запит, тому вам не потрібно турбуватися про це у вашому коді.

На даний момент ми щойно переробили параметризовані запити.

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

Кодування важко зробити правильно, а кодування-зроблено-правильно не відрізняється від параметризації.

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

import {sql} from 'cool-sql-library'

let result = sql`select *
    from users
    where user_id = ${user_id}
      and password_hash = ${password_hash}`.execute()

console.log(result)

У варіанті 1 ви працюєте з вхідним набором size = нескінченність, який ви намагаєтеся зіставити на дуже великий розмір виводу. У варіанті 2 ви обмежили свій внесок до того, що ви оберете. Іншими словами:

1. Ретельно перевіряйте та фільтруючи [ нескінченність ] для [ всіх безпечних запитів SQL ]
2. Використання [попередньо розглянутих сценаріїв, обмежених вашим обсягом ]

Згідно з іншими відповідями, також існує певна користь від обмеження вашої сфери дії від нескінченності та до чогось керованого.

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

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

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

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

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

Я про це пише Alredy тут: https://stackoverflow.com/questions/6786034/can-parameterized-statement-stop-all-sql-injection/33033576#33033576

Але просто для простоти:

Спосіб параметризованих запитів полягає в тому, що sqlQuery надсилається як запит, і база даних точно знає, що буде робити цей запит, і лише після цього він буде вставляти ім'я користувача та паролі лише як значення. Це означає, що вони не можуть здійснити запит, оскільки база даних вже знає, що буде робити. Тож у цьому випадку буде шукати ім'я користувача "Ніхто АБО 1 = 1" - "та порожній пароль, який повинен з’явитися помилковим.

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

Я ніколи не використовував SQL. Але очевидно, ви чуєте про те, які проблеми мають люди, і у розробників SQL були проблеми з цим "ін'єкцією SQL". Тривалий час я не міг це зрозуміти. І тоді я зрозумів, що люди, де створюються SQL-заяви, справжні текстові висловлювання SQL-джерела, об'єднуючи рядки, з яких деякі куди входять користувачем. І моя перша думка про це усвідомлення була шоком. Тотальний шок. Я подумав: Як хто може бути таким смішно дурним і створювати заяви на будь-якій мові програмування? Для розробників C, або C ++, або Java, або Swift це повне безумство.

З цього приводу, не дуже складно написати функцію C, яка приймає рядок C за свій аргумент, і створює інший рядок, який виглядає точно як літеральний рядок у вихідному коді C, який представляє ту саму рядок. Наприклад, ця функція перекладе abc на "abc", а "abc" в "\" abc \ "" і "\" abc \ "" в "\" \\ "abc \\" \ "". (Ну, якщо це здається вам неправильним, це html. Це було правильно, коли я його набрав, але не тоді, коли він відображається) І коли ця функція C написана, зовсім не складно створити вихідний код C, де текст із поля введення, що надається користувачем, перетворюється на літеральний рядок C. Це не важко зробити безпечним. Чому розробники SQL не використовуватимуть такий підхід як спосіб уникнути ін'єкцій SQL - це не за мене.

"Санітизація" - це цілком хибний підхід. Фатальна вада полягає в тому, що це робить певні введення користувача незаконними. Ви отримуєте базу даних, де загальне текстове поле не може містити такий текст; Таблиця викидання або все, що ви використовуєте для ін'єкції SQL, щоб заподіяти шкоду. Я вважаю це зовсім неприйнятним. Якщо база даних зберігає текст, він повинен мати можливість зберігати будь-який текст. І практичний недолік полягає в тому, що дезінфікуючий засіб, здається, не може зробити це правильно :-(

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

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

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

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

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

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

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