В чем разница между AddSlashes PHP и MySQL (i) _escape_String? [дублировать

Question

Возможный дубликат:
mysql_real_escape_string vs addslashes

Если они не делают точно так же, в чем разница? Разделитель для значений внутри запроса MySQL - это ' не так ли? Или, может быть " Но это также сбежало с добавками.

В других двигателях баз данных я понимаю (и определенно в обертке БД, такой как PDO), но почему так много людей, которые так называют MySQL (i) _escape_String вместо администрации?

Answer 1

Прежде всего: не используй mysql_escape_string, это устарело (по причине)!

Если вам нужно поддерживать устаревшее приложение, которое подключается к базе данных через mysql расширение (которое был устарел), использовать mysql_real_escape_string вместо. В противном случае Переключите немедленно к mysqli, где подготовленные операторы и связанные параметры обеспечивают более надежный механизм для избежания пользовательского ввода.

Тем не менее, ответ можно найти, прочитав описание mysql_real_escape_string а также addslashes:

Разница № 1

addslashes ничего не знает о кодировках соединения MySQL. Если вы передаете ему строку, содержащую байты, представляющие кодирование, отличное от кодирования, используемого соединением MySQL, она с радостью избежит Все байты имеют значения символов ', ", \ а также \x00. Анкет Это может быть не так, как все персонажи ', ", \ а также \x00 Если вы используете кодирование, отличные от 8-битных кодировки и UTF-8. Результатом будет то, что строка, полученная MySQL, будет повреждена.

Чтобы вызвать эту ошибку, попробуйте использовать iconv Чтобы преобразовать вашу переменную в UTF-16, а затем избежать ее с помощью addslashes. Анкет Посмотрите, что получает ваша база данных.

Это одна из причин, почему addslashes Не следует использовать для побега.

Разница № 2

В отличие от addslashes, mysql_real_escape_string Также ускользает от персонажей \r, \n, а также \x1a. Анкет Похоже, что эти персонажи также должны сбежать при разговоре с MySQL, в противном случае может быть узорный запрос

Это другая причина, почему addslashes Не следует использовать для побега.

Answer 2

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

Как это помогает? Если я хочу попробовать атаку в инъекции SQL на базу данных MySQL, сбежать отдельные кавычки с помощью BackSlash - это облом. Однако, если вы используете AddSlashes (), мне повезло. Все, что мне нужно сделать, это ввести что-то вроде 0xbf27, и addslashes () изменяет это, чтобы стать 0xbf5c27, допустимым мульти-байтовым символом, за которым следует одна цитата. Другими словами, я могу успешно ввести одну цитату, несмотря на ваш побег. Это потому, что 0xbf5c интерпретируется как единственный символ, а не два. Упс, там идет обратная черта.

....

Несмотря на использование AddSlashes (), я могу успешно войти в систему, не зная действительного имени пользователя или пароля. Я могу просто использовать уязвимость инъекции SQL.

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

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

Answer 3

Они идентичны тем, что вы не должны использовать ни один из них, потому что вы должны использовать заполнители, а не строить SQL из ненадежных данных.

Видеть http://bobby-tables.com/php.html для того, как сделать это правильно.

Answer 4

Это, прежде всего, проблема в Чарсете. какая addslashes() Было бы достаточным для сбежания данных, смешанных с командами SQL, если данные были чисто Асии. Анкет Но помимо изменений кодирования UTF-8, MySQL в какой-то конфигурации также позволяет Fringe Charsets, такие как UCS2 (UTF-16) или китайские Charsets GB/BIG5. Там недостаточно просто избежать сырого кода ASCII ' в \'. Анкет А потом способ избежать струн MySQL никогда не был очень совсем совместимым с SQL-Standards с самого начала. Это может быть устарело в будущих выпусках сервера MySQL.