Параметризованные операторы SQL и очень простой метод

Question

Когда я начал писать первые SQL-операторы в своих программах, я чувствовал себя вполне комфортно, защищая себя от SQL-инъекций очень простым методом, который мне показал коллега. Он заменил все одинарные кавычки на две одинарные.

Так, например, есть поле поиска, в котором вы можете ввести имя клиента для поиска в таблице клиентов. Если вы введете

Питерская парикмахерская

Оператор SELECT будет выглядеть как

SELECT *
FROM Customers
WHERE Customername = 'Peter''s Barbershop'

Если теперь злоумышленник вставит это:

';DROP TABLE FOO; --

Заявление будет выглядеть так:

SELECT *
FROM Customers
WHERE Customername = ''';DROP TABLE FOO;--'

Это не приведет к удалению какой-либо таблицы, но будет искать в таблице клиента имя клиента '; DROP TABLE FOO; - которое, я полагаю, не будет найдено; -)

Теперь, спустя некоторое время написания операторов и защиты от SQL-инъекций с помощью этого метода, я прочитал, что многие разработчики используют параметризованные операторы, но я никогда не читал статью, где использовался «наш» метод. Так что, безусловно, есть веская причина для этого.

Какие сценарии будут охватывать параметризованные операторы, а наш метод - нет? Каковы преимущества параметризованных операторов по сравнению с нашим методом?

Спасибо
Philipp

Answer 1

Параметризованные запросы имеют больше процессов, чем защита от sql-инъекций.

1. Это решает проблему с форматированием даты и времени и анализом.
2. Вы можете подготовить план выполнения для параметризованного запроса.
3. Защита от впрыска sql.

Я не могу вспомнить сейчас о других профи:).

Однако способ «удваивать каждые кавычки» имеет проблему с полями с ограниченной длиной символов.

Например:

• На странице есть поле для псевдонима, длина которого может быть 10 символов.
• Пользователь вставляет «пофиг» - точные 10 символов.

Теперь, если вы удвоите кавычки, значение будет иметь 11 символов, и база данных "обрежет" его, и вы получите другое значение в дБ, чем введенное пользователем.

Поэтому я рекомендую параметры.

Answer 2

Один большой недостаток заключается в том, что ваше решение зависит от разработчика, который помнит о добавлении символа, очевидно, компилятор не будет жаловаться. Это опасно.

Во-вторых, производительность должна быть повышена с помощью параметризованных операторов SQL, как указывает Джефф здесь (в 2005 !!!).

Answer 3

Краткий ответ:
Вы должны использовать параметризованные запросы просто потому, что сервер баз данных знает лучше, чем вы, какие символы необходимо экранировать.

Длинный ответ:
' не обязательно единственный специальный символ, который нужно экранировать. Эти специальные символы отличаются от сервера БД к серверу БД. MySQL, например, также использует \ в качестве escape-символа (если не установлено sql_mode=NO_BACKSLASH_ESCAPES). Следовательно, '' и \' означают одно и то же.

Это не относится, скажем, к Oracle.

Answer 4

Одним из преимуществ является то, что водитель сам определит, что ему нужно бежать, а что не нужно бежать. Ваш метод может быть поврежден с помощью такого ввода:

  \'; DROP TABLE foo;--

Что приведет к

  SELECT *
  FROM Customers
  WHERE Customername = '\'';DROP TABLE FOO;--'

Первая кавычка экранируется, вторая - нет и закрывает строку.

Answer 5

Каковы преимущества параметризованные утверждения по сравнению с наш метод?

Преимущество в том, что сложнее ошибиться; Вы не можете использовать параметризованный метод и забыть заменить кавычки. Кроме того, замена кавычек уязвима, если вы сделаете это дважды.

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