MySQL / PHP - экранирование символов, которые могут замедлить мою базу данных (или заставить ее работать неожиданно) - PullRequest
4 голосов
/ 04 декабря 2008

Я запускаю все свои целые числа через (int)Integer, чтобы сделать их безопасными для использования в моих строках запроса.

Я также запускаю свои строки через этот код функции: -

if(!get_magic_quotes_gpc()) {
           $string = mysql_real_escape_string($string);
        }

$pattern = array("\\'", "\\\"", "\\\\", "\\0");
$replace = array("", "", "", "");
if(preg_match("/[\\\\'\"\\0]/", str_replace($pattern, $replace, $string))) $string = addslashes($string); 


$cleanedString = str_replace('%','',$string);

Я, очевидно, возвращаю переменную $ cleanedString. Теперь я заменяю символ%, потому что это подстановочный знак для mySQL, и он может замедлить мои запросы (или заставить их вернуть неверные данные), если пользователь вставит их. Есть ли какие-то другие специальные символы для MySQL, о которых я должен беспокоиться?

Во второй ноте, есть ли что-то неправильное или избыточное в моем поиске и замене после mysql_real_escape_string? Я получил его с веб-сайта, когда только начинал, и (если я правильно помню) он сказал, что вы должны использовать этот поиск / замену в дополнение к escape-строке. Похоже, он пытается удалить ранее экранированные символы инъекции?

Ответы [ 5 ]

7 голосов
/ 04 декабря 2008

Хорошо, у меня есть несколько комментариев:

  • Функция магического цитирования устарела , ваша среда PHP никогда не должна включать магические кавычки. Поэтому проверять его не нужно, если только вы не разрабатываете код, который может быть развернут в средах других клиентов, которые (непреднамеренно) включили магические кавычки.

  • Регулярное выражение в вашем preg_match() неверно, если вы ищете последовательности символов. Регулярное выражение типа [xyz] соответствует любому одному из отдельных символов x, y или z. Он не соответствует строке xy или yz. В любом случае, это академично, потому что я не думаю, что вам вообще нужно искать или заменять специальные символы.

  • mysql_real_escape_string() достаточно для экранирования строковых литералов, которые вы намереваетесь интерполировать внутри кавычек в строках SQL. Нет необходимости выполнять подстановку строк для других кавычек, обратной косой черты и т. Д.

  • % и _ являются подстановочными знаками в SQL только при использовании сопоставления с шаблоном с выражениями LIKE. Эти символы не имеют смысла, если вы просто сравниваете их с операторами равенства или неравенства или регулярными выражениями. Даже если вы используете выражения LIKE, вам не нужно экранировать эти символы для защиты от внедрения SQL. Вам решать, хотите ли вы обращаться с ними как с буквальными символами (в этом случае экранировать их обратной косой чертой) или с подстановочными знаками в выражении LIKE (в этом случае просто оставить их внутри).

  • Все вышеперечисленное применяется, когда вы интерполируете переменные PHP в выражения SQL вместо буквенных строковых значений. Экранирование вообще не требуется, если вместо интерполяции вы используете связанные параметры запроса . Связанные параметры недоступны в простом API «mysql», но только в API «mysqli».

  • В другом случае вы интерполируете переменные PHP вместо имен таблиц SQL, имен столбцов или другого синтаксиса SQL. Вы не можете использовать связанные параметры в таких случаях; связанные параметры only занимают место строковых литералов. Если вам нужно сделать имя столбца динамическим (например, ORDER BY столбец предпочтений пользователя), вам следует разделить имя столбца обратными кавычками (в MySQL) или квадратными скобками (Microsoft) или двойные кавычки (другой стандартный SQL).

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

$quotedString = mysql_real_escape_string($string);

Это , если вы собираетесь использовать строку для интерполяции; если вы собираетесь использовать его в качестве значения связанного параметра, это еще проще:

$paramString = $string;
3 голосов
/ 04 декабря 2008

Да, я думаю, у вас там немного странно.

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

Если вы особенно хотите удалить подстановочный знак%, вы можете просто убрать его или удалить вообще. Прежде чем вставить строку в запрос SQL, наконец, запустите ее через mysql_real_escape_string, и все будет хорошо.

$string = $_POST['searchTerm'];
if (get_magic_quotes_gpc()) {
    $string = stripslashes($string);
}
$string = str_replace("%", "", $string);
$safeString = mysql_real_escape_string($string);
2 голосов
/ 04 декабря 2008

Если вы действительно беспокоитесь о проблемах внедрения SQL, вам настоятельно рекомендуется использовать подготовленные операторы. Поскольку оператор SQL оценивается перед предоставлением любых ваших пользовательских данных, ваш код намного безопаснее.

См. PDO и Mysqli

2 голосов
/ 04 декабря 2008

mysql_real_escape_string () экранирует эти символы для вас:

\ x00, \ n, \ r, \, ', "и \ x1a

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

if(get_magic_quotes_gpc()) {
    $string = stripslashes($string);
}

$string = mysql_real_escape_string($string);

$cleanedString = str_replace('%','',$string);

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

0 голосов
/ 04 декабря 2008

По второму пункту:
Он полностью избыточен, все символы были правильно экранированы, если вы запустите его через mysql_real_escape_string ()

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...