Mysql_real_escape_string VS добавляет

Может кто-то пролить свет на различия между этими двумя функциями, из руководства PHP

addslashes: Возвращает строку с обратными косыми чертами перед символами, которые должны быть указаны в запросах базы данных и т.д. Эти символы представляют собой одинарные кавычки ('), двойную кавычку ("), обратную косую черту() и NUL (байт NULL).

mysql_real_escape_string: mysql_real_escape_string() вызывает библиотечную функцию MySQL mysql_real_escape_string, которая добавляет обратную косую черту к следующим символам:\x00,\n,\r, \, ', "и\x1a.

из того, что я собираю, основное различие - это \x00,\n\r\x1a, которое не добавляет добавок, можете ли вы сказать мне, что это значимость?

спасибо

Ответы

Ответ 1

То, что вы цитируете, вероятно, из документа, но насколько я знаю, это не обязательно верно.

addslashes добавляет слэши к символам, которые обычно нарушают. mysql_real_escape_string ускользает от того, что MySQL нужно экранировать. Это может быть больше или меньше символов, чем то, что addslashes заботится.

Кроме того, mysql_real_escape_string не обязательно будет добавлять косые черты для выхода. Хотя я думаю, что это сработает, если вы сделаете это так, последние версии MySQL escape кавычек, поставив два из них вместе, вместо того, чтобы поместить косую черту перед ним.

Я считаю, что вы всегда должны использовать функцию escape-доступа поставщика данных вместо addslashes, потому что addslashes может делать слишком много или недостаточно работы для цели, которую вы используете. С другой стороны, mysql_real_escape_string знает, что делать, чтобы подготовить строку для вставки ее в запрос. Даже если спецификации меняются о том, как избежать лишних вещей, и вдруг это не обратная косая черта, которую вы должны использовать больше, ваш код будет работать, потому что mysql_real_escape_string будет знать об этом.

Ответ 2

mysql_real_escape_string() также учитывает набор символов, используемый текущим соединением с базой данных.

Функция PHP mysql_real_escape_string() использует функцию MySQL C API с тем же именем: http://dev.mysql.com/doc/refman/5.1/en/mysql-real-escape-string.html

Также читайте addslashes() в сравнении с mysql_real_escape_string() от известного эксперта по безопасности PHP Криса Шифлетта, за демонстрацию того, что вы можете использовать эксплойты SQL-инъекций даже если вы используете addlashes().

Другие люди рекомендуют использовать параметры запроса, а затем вам не нужно выполнять экранирование динамических значений. Я тоже рекомендую это, но в PHP вам придется переключиться на PDO или ext/mysqli, потому что простой ext/mysql API не поддерживает параметры запроса.

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

Ответ 3

Была история с mysql_escape_string и mysql_real_escape_string. Они оба пытались создать "общий" механизм экранирования, который минимизировал вероятность атаки SQL-инъекций.

mysql_real_escape_string и addslashes в порядке, если они вам нужны, но они, вероятно, не так.

Как говорит @afrazier, вы должны использовать подготовленные заявления

Ответ 4

Вместо того чтобы готовить запросы с использованием PDO, вы можете использовать это, в то время как ваше приложение использует MySQLi (остерегайтесь! "i" at и of Mysql ")

$nick = $connect->real_escape_string($nick);
$nick= addcslashes($nick, '%_');

$pass = $connect->real_escape_string($pass);
$pass = addcslashes($pass, '%_');

Ответ 5

Игнорировать оба и просто использовать параметризованные запросы. Если, конечно, вам не нравятся инъекции.