Почему использование подготовленного оператора mysql более безопасно, чем использование обычных escape-функций?

Question

В другом вопросе есть комментарий, который говорит следующее:

"Когда дело доходит до запросов к базе данных, всегда старайтесь использовать готовый параметризованные запросы. Мысли и Библиотеки PDO поддерживают это. Это бесконечно безопаснее, чем использовать побег такие функции, как mysql_real_escape_string. "

Источник

Итак, я хочу спросить: почему подготовленные параметризованные запросы более безопасны?

Answer 1

Важным моментом, который, по-моему, здесь не хватает, является то, что в базе данных, которая поддерживает параметризованные запросы, не нужно «избегать» беспокойства. Механизм базы данных не объединяет связанные переменные в оператор SQL, а затем анализирует все; Связанные переменные хранятся отдельно и никогда не анализируются как общий оператор SQL.

Вот откуда взялись безопасность и скорость. Механизм базы данных знает, что заполнитель содержит только данные, поэтому он никогда не анализируется как полный оператор SQL. Ускорение происходит, когда вы готовите оператор один раз, а затем выполняете его много раз; канонический пример - вставка нескольких записей в одну таблицу. В этом случае ядро ​​базы данных должно анализировать, оптимизировать и т. Д. Только один раз.

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

Answer 2

С одной стороны, вы оставляете скрытыми опасные символы в базе данных, которая намного безопаснее, чем вы, человек.

... он не забудет сбежать или пропустить какие-либо специальные символы, которые могут быть использованы для внедрения вредоносного SQL. Не говоря уже о том, что вы можете получить улучшение производительности при загрузке!

Answer 3

Я не очень разбираюсь в безопасности, но вот объяснение, которое, я надеюсь, поможет вам:

Допустим, у вас есть утверждение типа:

выберите [целое число] из mydb

Представьте, что когда вы его готовите, оператор скомпилирован в байты в нашей воображаемой реализации sql.

           01                  00 00                  23
Opcode for select          Prepared bytes      number of "mydb"
                          for your integer

Теперь, когда вы выполните, вы вставите число в пространство, зарезервированное для вашего подготовленного оператора.

Сравните это с тем, что если вы просто используете escape, вы можете вставить туда столько тарабарщины и, возможно, вызвать переполнение памяти, либо какую-то команду bizzare sql, которую они забыли экранировать.

Answer 4

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

mysql_real_escape_string так же безопасен, как и подготовленные операторы, ЕСЛИ вы не забываете использовать mysql_real_escape_string каждый раз, когда вызываете mysql_query, но это легко забыть.

Answer 5

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

(Есть и другие способы быть неуверенными.)

Answer 6

Функция небезопасна из-за этого эксплойта. http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string.. Поэтому подготовленные операторы предпочтительнее, и это также повышает производительность.

Answer 7

В лучшем случае это может быть не так, но, по крайней мере, в равной степени безопасно; и зачем рисковать?