Экранирование значения для MySQL просто добавляет обратную косую черту перед следующими символами: NULL
\n
\r
\
'
"
и 0x1A
. Больше ничего не делает.
«Экранированное» значение не является магически безопасным для использования в SQL. Экранирование предотвращает неправильную интерпретацию специальных символов (например, кавычек). Но если вы вставите экранированное значение в SQL-запрос, не заключая его в кавычки, то вы полностью упустили этот момент, и вы не более безопасны, чем в противном случае.
Помните, что процедура безопасности - , кавычка и побег . Вы всегда должны использовать эти два вместе, так как ни один не безопасен без другого.
Кроме того, если вы можете абсолютно гарантировать, что ваше входное значение не содержит ни одного из вышеперечисленных символов, то вы также можете быть уверены, что ваша экранированная строка всегда будет идентична неэкранированной, и, следовательно, экранирование не выполняет никаких дополнительных целей в этих условиях. .
Но что еще более важно:
Наконец, в ретроспективе мы поняли, что SQL был плохо спроектирован с точки зрения безопасности, и полагаться на то, что пользователи правильно цитируют и экранируют свои данные, это просто очень плохая идея.
Параметризованные запросы являются решением, поскольку они надежно отделяют данные от управляющей структуры. Параметризованные запросы возможны в mysqli с помощью prepare () , за которым следует bind_param () . При использовании этого метода экранирование не требуется, , и вы можете быть уверены, что абсолютно защищены от атак SQL-инъекцией.