В другом вопросе есть комментарий, в котором говорится следующее:
«Когда дело доходит до запросов к базе данных, всегда старайтесь использовать подготовленные параметризованные запросы. Библиотеки mysqli и PDO поддерживают это. Это намного безопаснее, чем использование экранирующих функций, таких как mysql_real_escape_string».
Итак, я хочу спросить: почему подготовленные параметризованные запросы более безопасны?
Важный момент, который, я думаю, люди здесь упускают, заключается в том, что с базой данных, поддерживающей параметризованные запросы, не о чем беспокоиться. Механизм базы данных не объединяет связанные переменные в оператор SQL, а затем анализирует все это целиком; Связанные переменные хранятся отдельно и никогда не анализируются как общий оператор SQL.
Отсюда безопасность и скорость. Механизм базы данных знает, что заполнитель содержит только данные, поэтому он никогда не анализируется как полный оператор SQL. Ускорение происходит, когда вы подготавливаете оператор один раз, а затем выполняете его много раз; каноническим примером является вставка нескольких записей в одну и ту же таблицу. В этом случае механизму базы данных необходимо выполнить синтаксический анализ, оптимизацию и т. д. только один раз.
Теперь одна проблема связана с библиотеками абстракции баз данных. Иногда они имитируют это, просто вставляя связанные переменные в оператор SQL с надлежащим экранированием. Тем не менее, это лучше, чем делать это самому.
Во-первых, вы оставляете возможность экранирования опасных символов базе данных, которая намного безопаснее, чем вы, человек.
... он не забудет экранировать или пропустить какие-либо специальные символы, которые можно использовать для внедрения какого-либо вредоносного SQL. Не говоря уже о том, что вы могли бы получить улучшение производительности для загрузки!
Я не очень разбираюсь в безопасности, но вот объяснение, которое, я надеюсь, поможет вам:
Допустим, у вас есть утверждение вроде:
выберите [целое число] из mydb
Представьте, что когда вы его готовите, оператор скомпилирован в байты в нашей воображаемой реализации SQL.
01 00 00 23
Opcode for select Prepared bytes number of "mydb"
for your integer
Теперь, когда вы выполняете, вы вставите число в место, зарезервированное для вашего подготовленного оператора.
Сравните это с тем, что если вы просто используете escape, вы можете вставить туда столько тарабарщины и, возможно, вызвать переполнение памяти или какую-то странную команду sql, которую они забыли экранировать.
Потому что с подготовленными утверждениями вы не можете забыть экранировать содержимое. Таким образом, нет никакого способа ввести ненадежность.
mysql_real_escape_string так же безопасен, как и подготовленные операторы, ЕСЛИ вы не забываете использовать mysql_real_escape_string каждый раз, когда вызываете mysql_query, но об этом легко забыть.
Функция небезопасна из-за этой уязвимости http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string. Вот почему предпочтительны подготовленные операторы, и это также дает улучшение производительности.
Подготовленные операторы решают фундаментальную проблему безопасности приложений, чем простая очистка данных. нет: они приводят к полному разделению данных и инструкций. Когда они путаются, возникает неуверенность. Это справедливо как для SQL-инъекций, так и для переполнения буфера.
(Есть и другие способы быть неуверенным.)
В лучшем случае это может быть не так, но, по крайней мере, в равной степени безопасно; а зачем рисковать?
