Параметризованные SQL-операторы по сравнению с очень простым методом
Когда я начал писать первые SQL-операторы в своих программах, я чувствовал себя вполне комфортно с защитой меня против Внедрения SQL с очень простым методом, который коллега показал мне. Это заменило все одинарные кавычки двумя одинарными кавычками.
Так, например, существует searchfield, в котором можно ввести customername для поиска в customertable. Если Вы вошли бы
Парикмахерская Peter
Оператор SELECT был бы похож
SELECT *
FROM Customers
WHERE Customername = 'Peter''s Barbershop'
Если теперь взломщик вставил бы это:
';DROP TABLE FOO; --
Оператор был бы похож:
SELECT *
FROM Customers
WHERE Customername = ''';DROP TABLE FOO;--'
Это не отбросило бы таблицы, но искало бы customertable customername'; НЕЧТО DROP TABLE; - который, я предполагаю, не будет найден ;-)
Теперь через некоторое время записи операторов и защиты меня против Внедрения SQL с этим методом, я считал, что многие разработчики используют параметризованные операторы, но я никогда не читал статью, где "наш" метод использовался. Так определенно существует серьезное основание для него.
То, какие сценарии параметризовали операторы, покроет, но наш метод не делает? Каковы преимущества параметризованных операторов по сравнению с нашим методом?
Спасибо
Philipp
5 ответов
Параметризованные запросы имеют больше процедур, чем защита от sql-инъекций.
- Решает проблему с форматированием и анализом даты и времени.
- Вы можете подготовить план выполнения для параметризованного запроса.
- Защита от sql-инъекций.
Не припомню еще одного профи :).
Однако способ "удваивать каждые кавычки" имеет проблему с полями с ограниченной длиной символа.
Например:
- На странице есть поле для «псевдонима», длина которого может составлять 10 символов.
- Пользователь вставляет «Неважно» - точные 10 символов.
Теперь, если вы удвоите кавычки, значение будет состоять из 11 символов, и база данных «вырежет» его, и вы получите другое значение в db, чем введено пользователем.
Поэтому рекомендую параметры.
Краткий ответ:
Вам следует использовать параметризованные запросы просто потому, что сервер базы данных лучше вас знает, какие символы нужно экранировать .
Длинный ответ:
' не обязательно единственный специальный символ, который нужно экранировать. Эти специальные символы отличаются от сервера БД к серверу БД. MySQL, например, также использует \ в качестве escape-символа (если не установлено sql_mode = NO_BACKSLASH_ESCAPES ). Следовательно, '' и \ ' означают одно и то же.
Это не относится, скажем, к Oracle.
Один большой недостаток состоит в том, что ваше решение полагается на разработчика, который не забыл добавить символ, очевидно, компилятор не будет жаловаться. Это опасно.
Во-вторых, производительность должна быть улучшена с помощью параметризованных операторов SQL, как указывает Джефф здесь (в 2005 !!!).
Одно из преимуществ состоит в том, что водитель сам определяет, что ему нужно убежать, а что нет. Ваш метод может быть нарушен вводом вроде этого:
\'; DROP TABLE foo;--
Что приведет к
SELECT *
FROM Customers
WHERE Customername = '\'';DROP TABLE FOO;--'
Первая кавычка экранируется, вторая - нет и закрывает строку.
Каковы преимущества параметризованных утверждений по сравнению с нашим методом?
Преимущество в том, что сложнее допустить ошибку; вы не можете сделать параметризованный метод и забыть заменить кавычки. Кроме того, замена кавычек уязвима, если вы делаете это дважды.
Недостатком параметризованных запросов (и причиной, по которой я никогда их не использую) является сложность. Вы можете написать в десять раз больше специальных запросов, прежде чем получите RSI.