mysqli подготовил заявления и mysqli_real_escape_string

Question

В настоящее время я использую расширение mysqli php.

Традиционно я использовал mysqli_real_escape_string, чтобы избежать пользовательского ввода. Однако я смотрю на изменение кода (возможно, в несколько этапов) для использования подготовленных операторов.

Я хочу прояснить это - при условии, что я использую подготовленные операторы для привязки всех своих переменных, могу ли я быть уверен, что SQL-инъекция невозможна? (И полностью отказаться от mysqli_real_escape_string?)

Спасибо

Answer 1

Говоря о безопасности, нет разницы между обоими методами, если вы правильно связываете или форматируете свои переменные.

Привязка просто проще, потому что она может использоваться только для любого случая, а экранирование не может (поэтому вы должны привести некоторые переменные вместо экранирования / цитирования)

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

Answer 2

Если вы правильно связываете все свои переменные, вы можете значительно снизить риск внедрения SQL-кода. Впрыскивание SQL все еще возможно, если вы создаете SQL динамически, например:

'SELECT * FROM ' . $tablename . ' WHERE id = ?'

Но если вы избегаете подобных вещей, вряд ли у вас будут проблемы.

Answer 3

Вот мой общий взгляд на тему.

При использовании динамических строк SQL вы полагаетесь на корректную работу escape-функции. К сожалению, это не всегда так, как видно из этого (по общему признанию) старого примера:

http://dev.mysql.com/doc/refman/5.0/en/news-5-0-22.html

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

Если вы используете подготовленные операторы с параметрами, оператор сначала анализируется и компилируется. Значения данных объединяются с скомпилированным оператором, когда он выполняется. Это отделяет логику SQL от значений данных - возможность перепутать два , если никогда не произойдет.

Так что, да, вы можете обойтись без mysqli_real_escape_string, но я бы не сказал, что использование подготовленных операторов с параметрами делает внедрение SQL невозможным. Это значительно усложняет задачу, но, как и в случае с ошибкой mysqli_real_escape_string, я полагаю, что всегда существует вероятность того, что еще не обнаруженная (или вновь созданная) ошибка сделает на первый взгляд невозможное возможным.