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

Question

Я запускаю все свои целые числа через (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-строке. Похоже, он пытается удалить любые ранее сбежавшие символы инъекций?

Answer 1

да, я думаю, что у вас есть вещи, идущие немного странно там.

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

Если вы особенно хотите удалить групповой символ%, вы можете просто избежать этого или удалить его вообще. Прежде чем вставить строку в 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); 

Answer 2

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

Answer 3

mysql_real_escape_string() сбегает эти символы для вас:

\ x00 \ п \ г, \,»," и \ x1a

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

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

$string = mysql_real_escape_string($string); 

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

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

Answer 4

Хорошо у меня есть несколько замечаний:

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

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

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

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

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

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

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

$quotedString = mysql_real_escape_string($string); 

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

$paramString = $string; 

Answer 5

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

См. PDO, и Mysqli