Возможный дубликат:
mysql_real_escape_string VS добавляет
Если они не делают то же самое, какая разница? Разделитель значений внутри запроса MySQL является ' не так ли? Или, может быть, " но это также ускользает от добавок.
В других механизмах базы данных я понимаю (и определенно внутри db-обложек, таких как PDO), но почему так много людей так любят использовать mysql (i) _escape_string вместо addlashes?
Прежде всего: не используйте 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
В отличие от mysql_real_escape_string , mysql_real_escape_string также избегает символов \r , \n и \x1a . Похоже, что эти символы также должны быть экранированы при разговоре с MySql, иначе может возникнуть искаженный запрос
Это и есть другая причина, почему addslashes не следует использовать для побега.
Крис Шифлетт демонстрирует реальный мировой случай, когда экранирование SQL с помощью метода addslashes() терпит неудачу, а mysql_real_escape_string() – единственный путь.
Как это помогает? Если я хочу попробовать атаку SQL-инъекции на базу данных MySQL, одиночные кавычки, скрытые с обратным слэшем, являются обломками. Однако, если вы используете addlashes (), мне повезло. Все, что мне нужно сделать, это ввести что-то вроде 0xbf27, а addslashes () модифицирует это, чтобы стать 0xbf5c27, действительным многобайтовым символом, за которым следует одиночная кавычка. Другими словами, я могу успешно вводить одну цитату, несмотря на то, что вы ускользаете. Это потому, что 0xbf5c интерпретируется как один символ, а не два. Ой, идет обратная косая черта.
….
Несмотря на использование addslashes (), я могу успешно войти в систему, не зная действительного имени пользователя или пароля. Я могу просто использовать уязвимость SQL-инъекции.
Чтобы избежать этого типа уязвимости, используйте mysql_real_escape_string (), подготовленные операторы или любую из основных библиотек абстракции базы данных.
теперь это, по общему признанию, редкий случай, но демонстрация того, почему люди так категоричны в отношении использования специальных функций выхода из базы данных. Только библиотека базы данных может точно знать, что такое экранирование. Различные оболочки, наборы символов и SQL-атрибуты (например, MS SQL-сервер) нуждаются в различном экранировании. Игнорирование этого факта – это то, как рождаются уязвимости.
Они идентичны в том, что вы не должны использовать ни один из них, потому что вы должны использовать заполнители вместо того, чтобы строить SQL из ненадежных данных.
См. http://bobby-tables.com/php.html, как это сделать правильно.
Это прежде всего проблема с кодировкой. То, что addslashes() действительно будет достаточным для экранирования данных, смешанных с командами SQL, если данные были чисто ASCII . Но помимо вариаций кодирования UTF-8, MySQL в некоторой конфигурации также допускает бахромы, такие как UCS2 (UTF-16) или GB / Big5. Там недостаточно, чтобы просто выйти из исходного кода ascii ' in \' . И тогда MySQL способ экранирования строк никогда не был очень совместим с SQL-стандартами. Он может быть устаревшим в будущих выпусках сервера MySQL.