Конкретный пример, где mysql_real_escape_string терпит неудачу, и Подготовленные Заявления необходимы

Question

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

Итак, я ищу недавний , конкретный пример того, где mysql_real_escape_string завершается ошибкой в ​​запросе, и решение состоит в том, чтобы использовать подготовленные операторы (т. Е. Нет никакой возможности для дальнейшей очистки ввода и гарантии ее безопасности) .

Я спрашиваю об этом, потому что единственный пример, который я смог найти, который удовлетворял вышеуказанным критериям, был некоторое время назад и с тех пор был исправлен в более современных версиях php.

Answer 1

Из документации PHP для функции (http://php.net/mysql_real_escape_string), говорится, что «mysql_real_escape_string () вызывает библиотечную функцию MySQL mysql_real_escape_string, которая добавляет обратный слеш к следующим символам: \ x00, \ n, \ r, \, ',"и \ x1a." Таким образом, его полезность зависит от контекста. Так, например, если бы у вас был следующий сценарий:

$user_input = mysql_real_escape_string($_GET['user_input']);
$query = "SELECT * FROM `users` WHERE `id` = $user_input";
$result = mysql_query($query);

Ну, это было бы довольно глупо. Потому что, если строка была 0 or 9=9, то это не содержит никаких символов, которые экранирует функция.Однако при введении в литерал $ query он выдает:

$query = "SELECT * FROM `users` WHERE `id` = 0 or 9=9";

Это вернет все строки в таблице users...... Что, вероятно, не является намерением программиста.

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

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

В приведенном выше примере самый безопасный способ обработки - использование функции intval () вместо функции mysql_real_escape_string ().

Надеюсь, что это имело смысл.

Answer 2

Целью mysql_real_escape_string() является 100% -ная гарантия того, что не может быть SQL-инъекций в данные, которые вы экранировали с его помощью.Он намного превосходит addslashes(), поскольку учитывает кодировку текущего соединения .

Если в реальной реализации этой функции нет критической ошибки, тогда использование .

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

Редактировать:

Обратите внимание напотенциальная возможность изменить набор символов соединения после его установления и, следовательно, выйти из синхронизации с mysql_real_escape_string.Я не подтвердил, что это все еще так.

Также обратите внимание, что mysql_real_escape_string() должна быть последней операцией, выполненной над данными перед объединением их с SQL.

Кроме того, не забывайте цитаты!Например.AND name = "' . mysql_real_escape_string($name) . '"

Answer 3

mysql_real_escape_string надежна на 100%.Это то, что вы делаете с экранированными данными после сбоя.

Например,

$safe = mysql_real_escape_string('some nasty injection-riddled data here');
$unsafe = htmlspecialchars($safe);

m_r_e_s отлично выполнит свою работу, а затем вы потенциально можете отменить все, поиграв со строкойзатем снова.

m_r_e_s должен быть ОЧЕНЬ последней операцией, выполненной над строкой, прежде чем она будет использована в запросе SQL.